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PREFACE 


This  Guide  for  Integrating  Systems  Engineering  into  DoD  Acquisition  Contracts  supports 
the  implementation  of  systems  engineering  (SE)  policy  initiatives  by  the  Under  Secretary  of 
Defense  for  Acquisition,  Technology  and  Logistics  (USD(AT&L))  stating  that  the  application  of 
“rigorous  system  engineering  discipline  is  paramount  to  the  Department’s  ability  to  meet  the 
challenge  of  developing  and  maintaining  needed  warfighting  capability.”  Primary  references 
include  the  following  USD(AT&L)  memoranda: 

•  Policy  for  Systems  Engineering  in  DoD,  USD(AT&L).  20  February  2004, 

•  Policy  Addendum  for  Systems  Engineering,  USD(AT&L),  22  October  2004 

•  Implementing  Systems  Engineering  Plans  in  DoD  -  Interim  Guidance,  USD(AT&L). 

30  March  2004T 

The  target  audience  for  this  guide  is  the  Government  program  team  responsible  for  (1) 
incorporating  program  technical  strategy  and  technical  planning  into  the  Request  for  Proposal 
(RFP)  and  (2)  performing  pre-award  functions,  including  source  selection,  as  well  as  post-award 
contractor  execution  activities.  The  guide  is  of  most  use  to  the  Program  Manager  (PM),  the  Lead 
(or  Chief)  Systems  Engineer  (LSE),  the  Contracting  Officer  (CO),  and  the  solicitation  team. 

The  primary  purpose  of  this  guide  is  to  aid  the  PM  and  LSE  to  effectively  integrate  SE 
requirements  into  appropriate  contracting  elements  in  support  of  system  acquisition;  however,  all 
Government  and  industry  personnel  involved  in  a  program  can  benefit  from  this  guide.  The 
authors  presume  the  reader  is  familiar  with  Department  of  Defense  (DoD)  governing  acquisition 
directive  and  instruction  (DoDD  5000.1,  USD(AT&L),  May  12,  2003,  and  DoDI  5000.2, 
USD(AT&L),  May  12,  2003)  and  the  Defense  Acquisition  Guidebook  (DAG).  For  example,  see 
DAG  Chapter  2,  Defense  Acquisition  Program  Goals  and  Strategy.  The  guide  also  aids  the  CO 
in  understanding  a  program’s  need  for  good  SE  requirements  as  part  of  any  systems  acquisition 
effort. 


The  guide  focuses  on  the  common  competitive-type  contract,  both  fixed-price  and  cost- 
reimbursable  (see  Federal  Acquisition  Regulations  (FAR  Part  16)),  applying  the  RFP  (FAR 
§15.203)  approach;  however,  users  may  be  able  to  tailor  the  technical  aspects  to  support  other 
acquisition  approaches,  such  as  sole  source;  purchase  of  commercial-off-the-shelf  (COTS) 
products  (e.g.,  software);  information  technology  (IT);  business  systems  or  services;  and  others. 
The  CO  is  responsible  for  all  contracting  aspects,  including  determining  which  type  of  contract  is 
most  appropriate.  Nothing  in  this  guide  should  be  construed  to  change  or  add  to  the 
requirements  of  existing  regulations,  directives,  instructions,  and  policy  memos. 

This  guide  applies  to  all  phases  of  the  acquisition  life  cycle  (see  DoD  Life  Cycle 
Acquisition  Framework).  For  simplicity,  however,  it  focuses  on  preparing  for  the  important 
System  Development  and  Demonstration  (SDD)  life  cycle  phase  (i.e.,  post  Milestone  B).  The 
content  of  the  guide  can  be  adapted  and  tailored  for  programs  entering  other  acquisition  life 
cycle  phases  (see  DAG  Chapter  4.  Systems  Engineering  and  DoDI  5000.2  for  more  details). 

Furthermore,  although  this  guide  does  not  reiterate  technical  SE  information  found  in  the 
DAG  or  in  the  Systems  Engineering  Plan  (SEP)  Preparation  Guide,  it  uses  the  DAG  (and  SEP 
guidance)  as  a  basis  for  guidance  noted  here  as  particularly  important.  This  guide  does  not 
elaborate  on  specialty  engineering  requirements  (e.g.,  Logistics/Sustainment  (including  Material 
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Readiness  (MR);  see  DAG  Chapter  5,  Life  Cycle  Logistics);  Test  and  Evaluation  (T&E)  (see 
DAG  Chapter  9,  Integrated  Test  and  Evaluation);  Modeling  and  Simulation  (M&S);  Information 
Assurance  (IA);  and  Architecture  (see  DAG  Chapter  7.  Acquiring  Information  Assurance  and 
National  Security).  Each  program  is  unique  and  needs  to  consider  which  technical  requirements 
and  solicitation  evaluation  criteria  are  important  to  include  in  the  RFP. 

This  guide  (1)  includes  brief  information  on  the  acquisition  and  contracting  process 
focused  on  technical  planning  and  subsequent  execution,  (2)  provides  examples  of  technical 
inputs  needed  for  the  solicitation  and  source  selection,  and  (3)  suggests  activities  immediately 
following  contract  award  to  assist  transition  into  the  SDD  phase.  The  examples  and  suggestions 
in  this  guide  should  be  considered  subject  to  the  direction  of  the  CO,  Source  Selection  Authority, 
or  other  higher  management. 

A  key  technical  objective  for  the  program  during  this  pre-Milestone  B  activity  is  to 
provide  the  potential  offerors’  information  describing  the  Government’s  program  technical 
approach  as  reflected  in  the  Government-developed  SEP  (DAG  §  4.5.1).  Also  provided,  as 
available,  would  be  the  Integrated  Master  Plan  (IMP;  DAG  $  4.5.2)  and  Integrated  Master 
Schedule  (IMS;  DAG  §  4.5.3)  to  form  a  baseline  for  the  offerors  to  respond  to  the  RFP. 

Although  the  DoDI  5000.2  does  not  require  approval  of  the  SEP  until  Milestone  B,  this  guide 
stresses  the  importance  of  early  technical  planning  (and  associated  documentation  in  the  SEP)  so 
that  the  Government’s  technical  strategy  can  be  reflected  in  the  RFP.  Other  key  artifacts  with 
technical  content  (e.g.,  Initial  Capabilities  Document  (ICD),  Analysis  of  Alternatives  (AoA) 
results,  Capabilities  Development  Document  (CDD),  Test  Evaluation  Strategy  (TES)  and/or  Test 
and  Evaluation  Master  Plan  (TEMP),  preliminary  System  Performance  Specifications  (SPS)) 
may  also  be  provided  to  offerors,  if  available  and  considered  appropriate. 

The  guide  includes  links  and  references  to  procurement  regulations  and  general 
acquisition  guidance  to  assist  the  reader  in  securing  more  detailed  information.  The  guide  is  not 
all-inclusive  but  is  meant  to  give  program  offices  a  starting  point  for  ensuring  that  contracts 
incorporate  SE  as  a  critical  element  in  any  system  acquisition.  The  authors  have  tried  to  avoid 
references  to  specific  service  or  agency  policies,  directives,  and  guidance,  as  each  organization 
will  need  to  consider  the  approach. 

The  Office  of  the  Secretary  of  Defense  (OSD)  office  of  primary  responsibility  (OPR)  for 
this  guide  is  DUSD(A&T),  Systems  and  Software  Engineering  /  Enterprise  Development 
(SSE/ED).  This  office  will  develop  and  coordinate  updates  to  the  guide  as  required,  based  on 
policy  changes  and  customer  feedback.  To  provide  feedback  to  the  OPR,  please  e-mail  the 
office  at  ATL-ED@osd.mil. 
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1  ACQUISITION  PROCESS 

This  guide  focuses  on  the  major  technical  elements  of  the  Government  acquisition 
process  as  defined  in  DoDD  5000.1,  The  Defense  Acquisition  System  and  DoDI  5000.2, 
Operation  of  the  Defense  Acquisition  System.  Figure  1-1  is  a  simplified  illustration  of  DoD’s 
acquisition  process  with  the  critical  component  of  contracting.  It  begins  when  the  warfighter 
identifies  the  need  ( see  Joint  Capabilities  Integration  and  Development  System  (JCIDS) 

3170. OlEj  to  the  acquisition  activity  who  then  translates  that  need  into  an  actionable  requirement 
and  purchase  request.  The  contracting  officer  (CO)  solicits  offers  from  industry  and  awards  a 
contract.  In  the  final  step,  the  contractor  closes  the  loop  by  delivering  products  and  services  that 
satisfy  the  Government  need.  During  acquisition  planning,  primary  responsibility  rests  with  the 
acquisition  activity. 


Figure  1-1  Simplified  Government  Acquisition  Process 

Acquisition  planning  is  the  process  of  identifying  and  describing  needs/capabilities/ 
requirements  and  determining  the  best  method  for  meeting  those  requirements  (e.g.,  business, 
program  Acquisition  Strategy),  including  solicitations/contracting.  Acquisition  planning  focuses 
on  the  business  and  technical  management  approaches  designed  to  achieve  the  program’s 
objectives  within  specified  resource  constraints.  The  Acquisition  Strategy,  usually  developed  in 
the  Technology  Development  phase  of  acquisition,  is  approved  by  the  Milestone  Decision 
Authority  and  provides  the  integrated  strategy  for  all  aspects  of  the  acquisition  program 
throughout  the  program  life  cycle.  The  Systems  Engineering  Plan  (SEP)  (SEP  Preparation 
Guide)  documents  the  program’s  system  engineering  strategy  and  is  the  blueprint  for  the 
conduct,  management,  and  control  of  the  technical  aspects  of  the  acquisition  program.  The 
Acquisition  Plan  provides  more  specific  plans  for  conducting  the  acquisition  and  is  approved  in 
accordance  with  agency  procedures  (FAR  Part  7).  A  Source  Selection  Plan  specifies  the  source 
selection  organization,  evaluation  criteria,  and  procedures,  and  is  approved  by  the  Contracting 
Officer  (CO)  or  other  Source  Selection  Authority  (SSA).  All  of  these  documents  guide  the 
development  of  the  Request  for  Proposal  (RFP). 
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It  is  important  that  the  program  team  have  strong  technical  and  contracting  leadership  as 
the  program  moves  through  its  steps  in  contract  formulation  and  execution.  It  is  imperative  to 
have  the  CO  involved  in  the  program  acquisition  planning  process  as  early  as  possible.  The 
Acquisition  Community  Connection  (ACC)  Practice  Center  Web  site  is  a  key  source  for  policy 
and  guidance.  Other  companion  program  artifacts  include,  for  example,  the  Capabilities 
Development  Document  (CDD),  Technology  Readiness  Assessment  (TRA),  Information  Support 
Plan  (ISP),  Test  and  Evaluation  Master  Plan  (TEMP),  Product  Support  Strategy  (PSS),  Support 
and  Maintenance  Requirements. 

1.1  Contracting  Process 

The  program  manager  (PM),  chief  or  lead  systems  engineer  (LSE),  and  a  CO  must  work 
together  to  translate  the  program’s  Acquisition  Strategy  and  Acquisition  Plan  and  associated 
technical  approach  (as  defined  in  the  Government  SEP)  into  a  cohesive,  executable  contract(s), 
as  appropriate.  Table  1-1  shows  some  key  contracting-related  tasks  with  indicators  of  roles  of 
the  PM  and  LSE. 


Table  1-1  Summary  of  Contracting  Activities  and  SE  and  PM  Roles 


Typical  Contract-Related  Activities 

System  Engineer  and  PM  Roles 

1 .  Identify  overall  procurement  requirements  and 
associated  budget.  Describe  the  Government’s 
needs  and  any  constraints  on  the  procurement. 

Lead  SE  (LSE)  provides  program  technical 
requirements.  PM  provides  any 
programmatic  related  requirements. 

2.  Identify  technical  actions  required  to  successfully 
complete  technical  and  procurement  milestones. 
The  program’s  SEP  is  the  key  source  for 
capturing  this  technical  planning. 

LSE  defines  the  technical 
strategy/approach  and  required  technical 
efforts.  This  will  be  consistent  with  the 
program’s  Acquisition  Strategy  and 
Acquisition  Plan  within  the  DoDI  5000.2 
requirements. 

3.  Document  market  research  results  and  identify 
potential  industry  sources.  See  FAR  Part  10  for 
sources  of  market  research  and  procedures. 

Small  Business  must  be  considered. 

PM  and  LSE  identify  programmatic  and 
technical  information  needed  and  assists  in 
evaluating  the  results. 

4.  Prepare  a  Purchase  Request,  including  product 
descriptions;  Priorities,  Allocations,  and 
Allotments;  architecture;  Government-furnished 
property  or  equipment  (or  Government-off-the- 
shelf  (GOTS);  Government-furnished 
information;  information  assurance  and  security 
considerations;  and  required  delivery  schedules. 

PM  and  LSE  ensure  the  specific 
programmatic  and  technical  needs  are 
defined  clearly  (e.g.,  commercial-off-the- 
shelf  (COTS)  products). 

5.  Identify  acquisition  streamlining  approach  and 
requirements,  budgeting  and  funding, 
contractor  vs.  Government  performance, 
management  information  requirements, 
environmental  considerations,  offeror  expected 
skill  sets,  and  milestones.  These  are  addressed 

The  procurement  team  work  together,  but 
the  CO  has  prime  responsibility  for  FAR 
and  the  Defense  FAR  Supplement 
(DFARS)  requirements.  The  PM  is  owner 
of  the  program  Acquisition  Strategy.  The 
LSE  develops  and  reviews  (and  PM 
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Typical  Contract-Related  Activities 

System  Engineer  and  PM  Roles 

in  the  Acquisition  Strategy  or  Acquisition  Plan. 

approves)  the  technical  strategy. 

6.  Plan  the  requirements  for  the  contract 

Statement  of  Objectives  (SOO)  /  Statement  of 
Work  (SOW)  /  specification,  project  technical 
reviews,  acceptance  requirements,  and 
schedule. 

LSE  is  responsible  for  the  development  of 
the  technical  aspects  of  the  SOO/SOW. 

See  FAR  Part  1 1 . 

7.  Plan  and  conduct  Industry  Days  as  appropriate. 

PM  and  LSE  supports  the  CO  in  planning 
the  meeting  agenda  to  ensure  technical 
needs  are  discussed. 

8.  Establish  contract  cost,  schedule,  and 
performance  reporting  requirements. 

Determine  an  incentive  strategy  and  appropriate 
mechanism  (e.g.,  Award  Fee  Plan  and  criteria). 

LSE  provides  technical  resource  estimates. 
LSE  supports  development  of  the  Work 
Breakdown  Structure  (WBS)  structure 
based  on  preliminary  system 
specifications;  determines  event-driven 
criteria  for  key  technical  reviews;  and 
determines  what  technical  artifacts  are 
baselined.  The  PM  and  LSE  advise  the  CO 
in  developing  the  metrics/criteria  for  an 
incentive  mechanism. 

9.  Identify  data  requirements 

LSE  identifies  all  technical  Contractor 

Data  Requirements  List  (CDRL)  and 
technical  performance  expectations. 

10.  Establish  warranty  requirements,  if  applicable. 

LSE  works  with  the  CO  on  determining 
cost-effective  warranty  requirements. 

11.  Prepare  a  Source  Selection  Plan  (SSP)  and 

RFP  (for  competitive  contracts). 

PM  and  LSE  provide  input  to  the  SSP  per 
the  SOO/SOW,  Sections  L  (Instructions  for 
Offeror)  and  M  (Evaluation  Factors)  of  the 
RFP. 

12.  Conduct  source  selection  and  award  the 
contract  to  the  successful  offeror. 

PM  and  LSE  participate  on  evaluation 
teams. 

13.  Implement  requirements  for  contract 
administration  office  memorandum  of 
agreement  (MO A)  and/or  letter  of  delegation. 

The  MOA  should  define  performance 
requirements/ attributes . 

PM  and  LSE  provide  input  regarding  the 
programmatic  and  technical  support  efforts 
to  be  included  in  the  MOA  and/or  letter  of 
delegation.  [PM  may  seek  DCMA 
support]. 

14.  Monitor  and  control  (M&C)  contract  execution 
for  compliance  with  all  requirements. 

PM,  LSE  and  program  team  perform 
programmatic  and  technical  M&C 
functions  as  defined  in  the  contract.  They 
also  assist  the  Earned  Value  Management 
(EVM)  implementation  by  defining  the 
criteria  for  completion  of  technical 
activity/delivered  products. 
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Typical  Contract-Related  Activities 

System  Engineer  and  PM  Roles 

15.  Contract  Close-out 

This  is  mostly  accounting/administration, 
but  CO  provides  status  to  PM. 

1.2  Important  Contract  Considerations  Affecting  Systems  Engineering 

The  following  contracting  aspects  may  affect  the  program’s  SE  efforts  and  products  and 
should  be  considered  in  solicitations: 

•  Organizational  Conflict  of  Interest  -  The  Government  acquisition  contracting  team 
needs  to  avoid  any  organizational  conflict  of  interest  (OCI)  in  SE  and  technical 
direction  work  to  be  performed  by  a  potential  contractor.  A  potential  OCI  exists 
when,  because  of  a  contractor’s  other  activities,  the  contractor  may  enjoy  an  unfair 
competitive  advantage,  or  when  award  of  the  subject  contract  could  put  the  contractor 
in  the  position  of  performing  conflicting  roles  that  might  bias  the  contractor’s 
judgment  (see  FAR  9.51.  The  CO  is  responsible  for  using  the  general  rules, 
procedures,  and  examples  in  the  FAR  to  identify  and  evaluate  potential  OCIs  as  early 
in  the  acquisition  process  as  possible  and  to  avoid,  neutralize,  or  mitigate  significant 
potential  conflicts  before  contract  award.  From  the  program’s  point  of  view,  they 
must  be  aware  that  any  current  or  previous  involvement  of  contractors  or  consultants 
in  aspects  of  this,  or  a  related,  program  may  preclude  the  opportunity  of  responding  to 
the  RFP  being  prepared.  High  standards  of  ethics  and  professionalism  are  expected 
of  every  participant  in  the  source  selection  process.  Any  questions  or  concerns  about 
procurement  integrity  or  standards  of  conduct  should  be  brought  to  the  agency  ethics 
official  or  the  CO. 

•  Commercial  Item  Acquisition  -  Market  research  will  determine  if  commercial  items 
(e.g.,  COTS)  or  non-developmental  items  are  available  and  may  meet  certain 
technical  requirements  of  the  program.  The  SE  (i.e.,  includes  LSE  and  other 
technical  staff-  logistics,  T&E,  IA,  etc.)  team  plays  a  key  role  in  supporting  the 
market  research  efforts,  analyzing  technical  attributes  and  associated  costs  related  to 
benefits  and  risks  of  various  such  options.  Generally,  however,  the  Government’s 
requirements  should  be  described  in  terms  of  performance  requirements.  This  is 
usually  part  of  the  Acquisition  Strategy.  It  should  be  left  to  the  offerors  (in  their 
proposals)  and  contractor,  in  design  documents  delivered  to  the  Government  for 
approval,  to  describe  the  planned  use  of  commercial  items. 

•  Incentive  Contracts  -  There  are  several  types  of  incentives,  such  as  award  fees,  to 
motivate  contractors  to  excel  in  performance,  and  reduce  risks  to  the  Government. 

The  CO  has  ultimate  responsibility  for  determining  contract  type  and  incentives  (see 
Incentive  Strategies  for  Defense  Acquisitions  Guide).  If  an  award  fee  type  contract 
will  be  used,  the  PM  and  LSE  will  assist  the  CO  to  develop  an  Award  Fee  Plan.  The 
award  fee  generally  should  be  associated  with  successful  completion  of  discrete 
events,  such  as  technical  reviews,  that  demonstrate  progress  toward  successfully 
completing  contract  requirements.  Other  award  fee  criteria  may  include  key  system 
performance  parameters  and  the  contractor’s  cost  and/or  schedule  performance. 
Consideration  should  be  given  to  using  existing  performance  metrics,  such  as  the 
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contractor’s  Earned  Value  Management  System  (EVMS)  and  other  SE  and  PM  tools 
(see  Section  2.4  for  more  discussion). 
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2  SYSTEMS  ENGINEERING  IN  ACQUISITION  PLANNING 

Systems  engineering  (SE)  is  an  overarching  process  that  the  program  team  applies  to 
transition  from  a  stated  capability  need  to  an  affordable,  operationally  effective  and  suitable 
system  (DAG  Chapter  4,  Systems  Engineering).  A  brief  overview  of  SE  is  provided  here  to  set 
the  stage  for  showing  how  it  becomes  a  critical  aspect  of  acquisition  contracts.  SE  encompasses 
the  application  of  SE  processes  across  the  acquisition  life  cycle  and  is  intended  to  be  an 
integrating  mechanism  for  balanced  solutions  addressing  capability  needs,  design  considerations 
and  constraints,  as  well  as  limitations  imposed  by  technology,  budget,  and  schedule.  SE  is  an 
interdisciplinary  approach  or  a  structured,  disciplined,  and  documented  technical  effort  to 
simultaneously  design  and  develop  system  products  and  processes  to  satisfy  the  needs  of  the 
customer  (DAG  §  4.1). 

During  the  program  acquisition  life  cycle  it  is  critical  that  an  “early  and  consistent” 
application  of  SE  begin  at  the  onset  of  a  program  (Concept  Refinement  and  Technology 
Development  (CR/TD)  phases).  It  is  recommended  that  a  program  SE  Integrated  Product  Team 
(SEIPT)  be  formed  early  in  the  acquisition  planning  activity  to  undertake  the  technical  planning 
activities.  A  Lead  or  Chief  Systems  Engineer  should  chair  the  SEIPT,  and  other  SE/technical 
Subject  Matter  Experts  (SMEs)  are  active  members,  e.g.,  T&E,  M&S,  Logistics/  Sustainment, 
Software  (SW),  IA,  security,  and  safety  engineering. 

For  those  programs  entering  directly  into  SDD  phase,  the  technical  effort  begins  long 
before  the  associated  Milestone  B  and  development  of  the  RFP.  The  program  Acquisition 
Strategy,  including  the  technical  approach,  should  be  documented  in  an  integrated  set  of 
Government  plans  that  includes  the  Acquisition  Strategy  (DAG  Chapter  2,  Defense  Acquisition 
Program  Goals  and  Strategy).  SEP  (DAG  §  4.5.1  and  SEP  Preparation  Guide).  Test  and 
Evaluation  Strategy  (TES)/TEMP  (DAG  Chapter  9,  Integrated  Test  and  Evaluation),  ISP  (DAG 
§  7.3.6).  Risk  Management  Plan  (Risk  Management  Guide  for  DoD  Acquisition).  Preliminary 
System  Performance  Specification  (or  equivalent),  Program  Budget,  Government  Roadmap 
and/or  Top  Level  Program  Schedule  (Integrated  Master  Plan  and  Integrated  Master  Schedule 
Preparation  (IMP/IMS)  and  Use  Guide).  These  activities  will  support  the  development  of  the 
Acquisition  Plan  and  SSP.  Building  on  this  solid  foundation,  the  RFP  should  reflect  the 
Government’s  policy  directives,  program  Acquisition  Strategy,  user  requirements  to  meet 
capability  needs,  and,  the  program’s  processes,  lessons  learned,  and  sound  practices  of  both 
Government  and  industry  (see  Figure  2-1). 

Regardless  of  the  scope  and  type  of  program  or  at  what  point  it  enters  the  program 
acquisition  life  cycle,  the  technical  approach  to  the  program  needs  to  be  integrated  with  the 
Acquisition  Strategy  to  obtain  the  best  program  solution. 
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Reviews  and  Approvals 


•  Milestone  Review 

•  Acquisition  Strategy 
Reviews  (Service  and 
program  peculiar) 


Program  Documents 


•  Acquisition  Strategy 

•  Top-Level  Program 
Plan  /  Program 
Schedule 

•  Preliminary  System 
Performance 
Specification 

•  WBS 

•  Systems  Engineering 
Plan  (SEP) 

•  Test  and  Evaluation 
Strategy  (TES)  /  Test 
and  Evaluation  Master 
Plan  (TEMP) 

•  ISP/TRA 

•  CONOPS / CDD / 

AoA 

•  ICE 

•  Program  Budget 


Solicitation  Planning 


•  Acquisition  Plan 

•  Incentive  Plan 

•  Source  Selection  Plan 


Typical  RFP* 


Contract  Schedule 
(Sections  A-J) 

B  -  CLINS  and  Prices 
C  -  Description/SOW 
D  -  Packaging/Marking 
E  -  Inspection/Accept. 

F  -  Delivery  Schedule 
G  -  Admin  Data 
H  -  Special  Provisions 


Section  J  -  Attachments 

-  Top  Level  Program  Plan  & 
Schedule 

-  Preliminary  System 
Performance  Specification 

-  Program  WBS 

-  SOO  or  SOW 

-  SEP  (as  appropriate  ) 

-  CDRLs 


Sections  L  &  M 

L  -  Instructions  to  Offerors 
M  -  Evaluation  Factors  for 
Award 


*  Section  K  is  by  reference 


Key  Program  Technical  Attributes 

•  Technical  “Enterprise”  Processes 

•  Integrated  approach  to  engineering,  test,  and 
logistics/sustainment 

•  Technical  approach  addressing  the  program’s  life  cycle 

•  Event-based  technical  reviews  with  independent  SMEs 

•  Single  Technical  Authority 

•  IPT-based  organization  derived  from  WBS 

•  Contractor’s  Capability 

•  Domain  expertise  coupled  with  “Enterprise  processes” 
using  experienced  personnel 

•  Proven  past  performance  (domain  and  process  areas) 

•  Technical  Planning 

•  Technical  approach  integrated  with  IMP/IMS  and  EVMS 

•  Viable  system  solution  employing  mature  technology 

•  Special  design  considerations  (MOSA,  IA,  security, 
safety,  etc.) 

•  Technical  Baseline 

•  Technical  baseline  management 

•  Requirements  management  and  traceability 

•  Product  measures  linked  to  technical  baseline  maturity, 
financial,  and  schedule  measures/metrics 

•  Incentives 

•  SE  excellence  that  results  in  superior  product 
performance  balanced  with  cost  and  schedule;  SBIR 

•  Cost  and  Schedule  Realism 

•  Realistic  program  budgets  -  optimized  program  cost, 
schedule,  and  performance 

•  Realistic  task  and  achievable  schedules  in  the  IMP/IMS 

•  Management  of  the  critical  path  and  near  critical  paths 

•  Data  Access 

•  Ownership,  control,  and  delivery  of  technical  baseline 
data  that  support  the  technical  and  support  strategy 

•  Timely  access  to  program  technical  data 


Figure  2-1  Relating  Acquisition  Program  Elements  to  RFP  and  Technical  Attributes 

2.1  Technical  Approach  and  the  Systems  Engineering  Plan  (SEP) 

The  technical  approach  for  the  program  begins  at  the  very  onset  of  a  program  and  is 
documented  in  the  SEP  and  related  plans  (e.g.,  Risk  Management  Plan).  Before  source  selection, 
the  SEP  reflects  the  Government’s  technical  approach  to  the  program  as  it  moves  through  the 
CR/TD,  SDD,  Production  and  Deployment  (P&D),  Operations  and  Support  (O&S)  program 
acquisition  life  cycle  phases.  As  defined  in  the  SEP  Preparation  Guide,  the  SEP  is  the  blueprint 
for  the  conduct,  management,  and  control  of  the  technical  aspects  of  an  acquisition  program  from 
conception  to  disposal,  i.e.,  how  the  SE  process  is  applied  and  tailored  to  meet  each  acquisition 
phase  objective.  The  process  of  planning,  developing,  and  coordinating  SE  and  technical 
management  forces  thoughtful  consideration,  debate,  and  decisions  to  produce  a  sound  SE 
strategy  for  a  program  commensurate  with  the  program’s  technical  issues,  life  cycle  phase,  and 
overall  objectives 

The  SEP  is  the  one  document  that  defines  the  methods  by  which  all  system  requirements 
having  technical  content,  technical  staffing  and  technical  management  are  to  be  implemented  on 
a  program,  addressing  the  government  and  all  contractor  technical  efforts.  [Note:  Until  a 
contractor  is  selected,  this  part  will  represent  high  level  expectations,  within  the  defined 
Acquisition  Strategy  and  Plan,  of  what  the  contractor  will  perform  to  be  consistent  and  integrated 
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with  the  Government’s  SEP],  A  few  key  contract  relevant  items  are  extracted  from  the  SEP 
Preparation  Guide  and  reiterated  here: 

•  The  SEP  is  about  overall  organization  of  the  technical  effort,  including  delineation  of 
authorities,  responsibilities,  and  integration  across  the  government  and  contractor 
boundaries. 

•  The  SEP  shows  how  the  SE  structure  is  organized  to  provide  technical  management 
guidance  across  the  government,  prime  contractor,  subcontractors,  and  suppliers. 

•  The  SEP  provides  an  overview  of  government  and  contractor  data  rights  for  the  system  to 
include  what  key  technical  information  and  data  will  be  developed  during  the  phase  being 
planned. 

•  The  SEP  summarizes  how  the  program’s  selected  Acquisition  Strategy  is  based  on  the 
technical  understanding  of  the  problem  at  hand  and  the  identified  program  risks  to 
include  the  list  of  program  risks. 

•  The  SEP  describes  how  the  contract  (and  subcontract  and  suppliers’,  if  applicable) 
technical  efforts  are  to  be  managed  from  the  Government  perspective. 

A  key  requirement  of  offerors’  responses  to  the  RFP  is  the  submission  of  a  fully 
integrated  technical  management  approach  that  is  expanded  from  the  Government  SEP  to  a  fully 
integrated  SEP  [Note:  traditionally  this  was  documented  in  a  SE  Management  Plan  (SEMP)] 
which  includes  the  offeror’s  technical  approach,  processes,  procedures,  tools,  etc.).  Also 
included  in  the  response  will  be  a  Contractor  SOW  (CSOW),  an  updated,  expanded,  and 
integrated  Contractor  WBS  (CWBS),  which  is  correlated  with  the  offeror’s  EVMS  (EYMS 
Implementation  Guide),  as  appropriate,  and  the  IMP/IMS. 

Following  the  source  selection  and  contract  award,  the  SEPs  evolve  into  a  Program  SEP 
(see  Section  4  of  this  guide),  documenting  the  Government  and  industry  shared  view  of  the 
technical  approach  and  planning  for  the  program.  For  contractual  and  management  efficiency, 
the  revised  Government  SEP  and  contractor’s  integrated  SEP  may  remain  as  two  separate 
documents  with  appropriate  links  in  an  Integrated  Development  Environment  (IDE)  to  ensure 
communication  and  configuration  control  across  the  Government  and  contractors  activities  and 
products  as  work  progresses  and  changes  are  authorized.  As  a  program  progresses  through  its 
life  cycle,  the  level  of  fidelity  and  areas  of  emphasis  in  the  SEP  will  change.  It  is  important  that 
the  program  team  have  a  single  vision  of  the  technical  planning  (therefore  the  individual  SEPs 
will  be  in  alignment)  and  execution  when  making  a  commitment  for  the  design,  development, 
test,  and  transition  of  a  system/product(s)  to  satisfy  user’s  operational,  logistics,  and  sustainment 
needs. 

2.2  System  Requirements 

Sound  system  requirements  (including  performance)  are  the  backbone  of  a  good  technical 
strategy  and  resultant  plan  (as  documented  in  the  SEP  and  related  plans).  The  performance 
requirements,  as  a  minimum,  must  be  commensurate  with  satisfying  the  threshold  for  the  critical 
operational  (including  sustainment  and  support)  requirements  (e.g.,  Key  Performance  Parameters 
(KPPs))  and  balanced  with  program  cost,  schedule,  and  risk  constraints.  If  these  elements  are 
not  balanced  at  the  start  of  the  SDD  phase,  the  program  has  a  high  probability  of  incurring  cost 
increases,  suffering  schedule  delays,  and/or  deficient  performance  of  the  end  product.  An 
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important  element  of  the  program’s  technical  plan  should  be  focused  on  maturing  the  technical 
baseline  via  event-based  technical  reviews  and  completeness  of  T&E  (SEP  Preparation  Guide 
and  DAG  Chapter  9.  Test  and  Evaluation)  while  managing  the  systematic  decomposition  and 
allocation  of  the  requirements  down  the  specification  hierarchy  (DAG  §  4.3.3).  Figure  2-2 
illustrates  the  relationships  among  requirements,  technical  reviews  and  technical  baseline. 


Requirements  Management  Maturing  Technical  Baseline 


*  See  definitions  in  Appendix  C  -  Acronyms 


Figure  2-2  Key  Technical  Relationships 

2.3  Systems  Engineering  in  the  Statement  of  Objectives  (SOO) 

When  the  Government  develops  a  SOO,  as  opposed  to  a  SOW,  in  the  RFP  (and  in 
attachment  J),  the  SOO  is  a  clear  and  concise  document  that  delineates  the  program  objectives 
and  the  overall  approach,  particularly  critical  (or  high  risk)  requirements  that  become  part  of  the 
trade  space.  The  TRA  will  support  this  identification.  Table  2-1  contains  suggested 
technical/SE  items  to  consider  including  in  a  SOO. 

The  SOO  does  not  become  part  of  the  subsequent  contract.  [Note:  A  SOW,  or  a  PWS,  is 
always  included]. 
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_ Table  2-1  Sample  SE  Items  for  a  SOO  during  the  SDD  Phase _ 

The  program’s  technical  approach  will  capitalize  on  Government  and  industry  standards, 

policies,  and  directives  while  leveraging  the  contractor’s  domain  experience  and 

“enterprise  processes.”  The  technical  objectives  for  the  program  are  to: 

1 .  Design,  develop,  test,  and  deliver  a  system  which  meets  the  performance 
requirements  of  the  user  when  operated  within  the  XXX  System-of-Systems  (SoS) 

(or  within  YYY  Family-of-Systems  (FoS)). 

2.  Use  contractor  “enterprise  processes”  to  execute  the  program.  Flow  down  policies 
and  processes  to  the  lowest  level  of  the  contractor  (subcontractors,  teammates,  or 
vendors)  team  as  appropriate.  Employ  continuous  process  improvement  activities 
integrating  both  Government  and  contractor  practices  and  processes.  Ensure 
Government  technical  processes,  as  defined  in  their  SEP,  are  integrated  and 
consistent  with  the  contractor  technical  processes. 

3.  Document  the  program’s  technical  approach  in  a  Program  SEP  (including  both 
Government  SEP  and  the  contractor  integrated  and  expanded  SEP)  that  is  updated 
throughout  the  life  of  the  program. 

4.  Implement  event-based  technical  reviews  that  are  included  in  the  IMP  and  IMS  with 
specific  entry  and  exit  criteria.  Technical  reviews  include  the  participation  of 
independent  (of  the  program)  subject  matter  experts. 

5.  Establish  interface  management  processes  which  define  the  inter-system  (SoS,  FoS) 
interfaces  and  intra-system  [subsystems,  Commercial-off-the-Shelf  (COTS), 
Government-off-the  Shelf  (GOTS),  etc.]  interfaces  to  support  system  development. 

6.  Use  contractor  configuration  management  (CM)  processes  to  control  the 
configuration  of  technical  baseline  data  and  product  configurations.  Provide  real¬ 
time  access  to  technical  product  data  for  program  participants.  Ensure  compatibility 
with  the  Government  CM  processes. 

7.  Enhance  opportunities  for  incorporation  of  advanced  technology  for  improved 
performance  and  sustainment  using  Modular  Open  Systems  Approach  (MOSA) 
principles.  Encourage  use  of  commercial  products  and  industry-wide  standards 
recognized  for  high  quality. 

8.  Use  modeling,  simulation,  prototypes,  or  other  means  to  allow  early  Government 
assessment  of  product  maturity  and  functional  capabilities  in  support  of  technical 
reviews  along  with  optimizing  system-level  testing. 

9.  Include  Government  participation  on  IPTs  to  gain  insight  into  program  progress  and 
streamline  the  coordination  and  decision  processes.  Ensure  compatibility  and 
integration  with  the  Government  defined  IPTs  (see  Government  SEP). 

10.  Implement  a  comprehensive  risk  management  process  that  is  focused  on  program  risk 
areas  and  the  program’s  critical  path(s)  to  systematically  identify  and  mitigate  cost, 
schedule,  and  technical  risks.  Ensure  Contractor  risk  management  processes  are 
compatible  with  the  Government  risk  management  process. 


The  guidance  for  the  SOO  is  generally  applicable  to  a  SOW  also. 
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2.4  Technical  Incentive  Strategies 

The  determination  and  development  of  an  incentive  strategy  begins  early  in  the  program. 
The  incentive  criteria  should  reflect  areas  of  performance  for  which  the  Government  wants  to 
encourage  performance  excellence  as  a  risk  reduction  activity.  A  contractual  incentive,  such  as 
an  award  fee  (refer  back  to  section  1.2),  should  focus  on  the  most  critical  SE  issues  and/or 
practices  (DAG  $  4.2.3  and  $  4.2.4).  Two  award  fee  examples  are  presented  for  illustration: 

Risk  Management  Incentive  -  A  contractor’s  risk  management  process  is  one  example 
of  an  award  fee  element  that  could  recognize  and  reward  a  contractor  that  strategically  focuses 
on  efficient  and  effective  management  practices.  Award  fee  criteria  may  include  the  extent  to 
which  the  risk  management  process  employed  on  the  acquisition  program  is  integrated  across  the 
government  and  contractor  team.  Sample  indicators  of  an  integrated  process  include: 

•  A  risk  management  process  in  which  shared  metrics  and  risk  management  systemic 
analysis  are  routinely  accomplished 

•  Use  of  a  single  risk  management  database  with  established  links  between  Risk 
Management/T echnical  Reviews/TPMs/EVM/WB  S/IMS 

•  Documented  traceability  of  mitigation  efforts 

•  A  risk  management  process  coupled  to  change  control  activities 

•  An  enterprise-level  view  of  risk  management  to  prevent  the  acquisition  program  from 
being  adversely  affected  by  other  enterprise  acquisition  programs  or  enterprise- wide 
challenges. 

The  risk  management  information  in  the  DAG  Chapter  4  and  in  the  Risk  Management 
Guide  for  DoD  Acquisition  are  sources  of  other  indicators  of  an  integrated  risk  management 
process. 

Technical  Reviews  Incentive  -  A  contractor’s  technical  review  process  is  considered 
extremely  important  to  program  success.  Award  fee  criteria  should  include  timely,  or  early, 
completion  of  design  reviews,  and  award  fee  should  be  reduced  or  eliminated  if  design  reviews 
are  critically  late.  . 

The  DAG  Chapter  4  elaborates  further  on  key  technical  reviews. 

An  important  element  of  any  award  fee  plan  is  to  ensure  that  key  criteria  are  measurable 
to  minimize  potential  for  subjective  evaluations  and  therefore  have  a  clear  understanding 
between  Government  and  contractor  regarding  performance  incentives. 

2.5  Government  and  Industry  Interaction 

There  should  be  an  environment  of  open  communication  prior  to  the  formal  source 
selection  process  (1)  to  ensure  industry  understands  the  Government  requirements,  and  that  the 
Government  understands  industry  capabilities  and  limitations;  and  (2)  to  enhance  industry 
involvement  in  the  Government’s  development  of  a  program  Acquisition  Strategy.  During  the 
pre-solicitation  phase,  the  Government  develops  the  solicitation  and  may  ask  industry  to  provide 
important  insights  into  the  technical  challenges,  program  technical  approach,  and  key  business 
motivations.  [Note:  The  CO  is  the  Government’s  principal  point  of  contact  with  industry].  For 
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example,  potential  industry  bidders  could  be  asked  for  their  assessment  of  proposed  system 
performance  that  is  achievable  based  on  the  maturity  level  of  new  technology  as  well  as  existing 
technology.  The  Government  takes  the  leadership  role  in  this  stage.  Lessons  learned  from  past 
programs  suggest  that  contract  formation  can  be  very  productive  when  a  highly  collaborative 
environment  is  created  involving  user,  acquisition,  sustainment,  and  industry  personnel  to 
understand  and  capture  the  technical  challenge  and  technical  and  programmatic  approaches 
needed  to  successfully  execute  a  program.  As  can  be  seen  from  the  Integrated  Defense  AT&L 
Life  Cycle  Management  Framework,  Market  Research  begins  early  in  the  life  cycle  (i.e.,  CR/TD 
phases)  as  part  of  initial  risk  analyses  activities.  The  CO  may  develop  and  provide  to  industry  a 
draft  RFP  to  enhance  an  understanding  of  the  customer  needs  and  the  industry’s  capabilities  to 
cost-effectively  meet  these  needs. 

2.5.1  Market  Research 

FAR  Parts  7,  10,  and  1 1  require  the  Government  to  conduct  acquisition  planning,  to 
include  market  research  (DAG  §  2.3.16.1.4.1  and  10  USC  2377),  as  a  way  to  establish  the 
availability  of  products  and  vendors  which  can  meet  potential  needs.  Market  research  supports 
the  acquisition  planning  and  decision  process  by  supplying  technical  and  business  information 
about  industry’s  technology,  products,  and  capabilities.  Market  research  can  be  used  to  obtain 
additional  information  on  a  company’s  technical  and  management  processes  capabilities  along 
with  their  domain  expertise  (DAG  §  4.2.5).  These  factors  can  be  assessed  during  source 
selection,  rather  than  by  market  research.  Market  research  should  also  be  used  to  identify  any 
required  sources  of  supplies  or  services  (FAR  Part  8)  and  restrictions  or  other  issues  regarding 
foreign  sources  of  supplies  (FAR  Part  25). 

2.5.2  Industry  Days 

Before  release  of  a  formal  RFP,  the  Government  may  hold  Industry  Days  to  inform 
industry  of  the  technical  requirements  and  acquisition  planning  plus  to  solicit  industry  inputs  for 
the  pending  program.  Both  large  and  small  businesses  should  be  encouraged  to  attend.  The  CO 
will  establish  the  agenda  for  Industry  Day  and  the  ground  rules  for  interchange  with  industry 
representatives.  Table  2-2  provides  some  example  technical-related  topics  for  Industry  Days. 
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_ Table  2-2  Example  Technical  Topics  for  Industry  Days _ 

1 .  The  Government  should  describe  its  commitment  to  the  program  and  how  it  fits  into  the 
Service’s  or  Agency’s  portfolio  of  programs — its  relationship  with  other  programs. 

2.  The  Government  should  emphasize  and  describe  its  overall  technical  approach  to  the 
program  and  the  interdependencies  with  cost  and  schedule.  The  Government  SEP 
should  be  made  available  to  industry  as  a  starting  point  for  their  technical  planning. 

3.  The  Government  and  industry  should  discuss  trades  and  analyses  that  have  been 
conducted  during  the  requirements-generation  process.  While  solution  alternatives  may 
be  discussed,  the  emphasis  should  remain  on  the  resulting  performance  (including 
supportability)  requirements,  not  on  the  specifics  of  the  alternatives.  [Note:  Some 
potential  offerors  may  choose  not  to  discuss  specifics  of  their  potential  alternative  in  the 
presence  of  potential  competitors.]  The  results  of  Government  trades  and  analyses 
should  be  made  available  to  industry  as  appropriate  JCIDS  documents:  AoA,  ICD,  draft 
CDD,  Concept  of  Operations  (CONOPS),  etc.  These  discussions  are  intended  to 
understand  the  specific  operational  and  sustainment  requirements  critical  to  the  program. 

4.  While  it  is  necessary  to  investigate  potential  design  solutions  that  are  responsive  to  the 
requirements,  the  Government  team  should  avoid  becoming  “fixated”  with  the  solutions. 
The  user  sometimes  becomes  enamored  with  what  he  “likes;”  the  program  team  focuses 
on  the  one  that  “works;”  and  industry  has  one  it  wants  to  “sell.”  The  focus  is  on 
establishing  the  cost-effective  system  performance  requirements  that  deliver  the 
necessary  warfighter  capability — not  picking  the  design  solution.  Industry  Days  should 
inform  the  solicitation  development,  not  define  a  solution. 

5.  The  Government  presentations  and  discussions  should  address  the  program  Acquisition 
Strategy,  the  SE  approach  as  being  developed  in  the  Government  SEP,  and  how  they 
were  established.  The  discussions  should  also  emphasize  the  importance  of  Total  Life 
Cycle  System  Management  (TLCSM)  (DAG  Chapter  5,  Life  Cycle  Logistics). 


2.5.3  Draft  Request  for  Proposal  (RFP) 

The  CO  may  release  a  draft  RFP  prior  to  a  formal  RFP  to  secure  industry  inputs, 
comments,  and  suggestions.  The  Government  team  should  make  the  draft  as  complete  as 
possible.  The  Government  should  allow  sufficient  time  (at  the  CO’s  discretion)  for  industry  to 
respond  and  should  seriously  consider  all  industry  suggestions  and  comments  and  modify  the 
solicitation,  as  appropriate  to  reflect  needed  changes.  After  the  formal  release  of  an  RFP,  the 
exchange  of  comments,  questions,  and  answers,  etc.,  regarding  the  RFP  become  strictly 
controlled  and  are  conducted  only  through  the  CO.  It  is  much  better  to  make  changes  before  the 
release  of  the  RFP  than  to  amend  it  afterward,  which  may  require  an  extension  of  proposal 
preparation  time. 

Although  Market  Research,  Industry  Days  and  draft  RFPs  are  important,  they  are  just 
three  of  many  tools  available  for  exchanging  information  with  industry.  Other  exchanges  of 
information  include  Industry  or  small  business  conferences;  public  meetings;  one-on-one 
meetings  with  potential  offerors  (with  the  approval  of  the  CO);  Pre-solicitation  notices;  Request 
for  Information  (RFI);  Pre-solicitation  or  pre-proposal  conferences;  and  Site  visits.  The  readers 
are  referred  to  the  FAR  and  the  DFARS  for  more  details. 
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2.6  Technical  Planning  in  the  Source  Selection  Plan  (SSP) 

The  SSP  describes  the  organization  of  the  source  selection  team  along  with  the  factors 
and  subfactors  included  in  Section  M,  Evaluation  Factors  (DFARS  Part  215).  The  program’s 
technical  appro ach J  n c  1  udi  n g  key  performance  parameters  and  risk^  should  be  reflected  in  the 
evaluation  factors.  [Note:  “Factors”  is  the  FAR/DFARS  term;  most  SE  /technical  personnel  use 
the  term  “criteria”  interchangeably].  Figure  2-3  illustrates  a  typical  Source  Selection 
Organization.  The  Source  Selection  Evaluation  Board  (SSEB)  oversees  the  evaluation  team’s 
activities  and  briefs  the  findings  to  the  Source  Selection  Authority,  which  makes  the  decision. 

The  Government’s  technical  authority  or  the  program’s  LSE  (DAG  §  4.1.6,  Systems 
Engineering  Leadership)  should  lead  the  technical  evaluation  team.  Technical  personnel  (to 
include  Government  SMEs,  e.g.,  system  safety,  security,  IA)  should  participate  on  each  panel  (or 
committee)  of  the  source  selection  organization  (see  Figure  2-3),  as  necessary  to  assess  each 
factor  and  subfactor  that  forms  the  basis  of  the  source  selection.  The  evaluation  factors  and  the 
subsequent  evaluation  rely  upon  personnel  who  are  qualified  in  the  functional  area  and  have  the 
past  experience  and  qualifications  necessary  to  make  an  assessment  on  proposal  credibility. 

The  technical  team  supporting  the  evaluation  should  include  representatives  from  the 
acquisition  organization,  including  the  Defense  Contract  Management  Agency  (DCMA), 
logistics/  sustainment,  other  appropriate  SMEs,  and  user  organizations.  To  ensure  continuity  and 
promote  a  smooth  transition  into  contract  execution,  personnel  who  will  be  involved  in  the 
program  should  also  be  involved  in  developing  the  SSP  and  evaluation  factors.  It  is  strongly 
recommended  that  a  qualified  (e.g.,  to  include  familiarity  with  the  Government  SEP) 
technical/SE  program  representative  also  be  involved  in  the  Management  and  Past  Performance 
evaluation  teams  since  these  teams  will  evaluate  technical  organization  structure,  skills,  abilities, 
experience,  and  technical/SE  management  best  practices  to  be  employed  by  the  offeror. 

Source  selection  procedures  should  minimize  the  complexity  of  the  solicitation  by  only 
requiring  the  information  necessary  to  make  a  decision  and  limiting  evaluation  factors/ 
subfactors  to  those  that  are  key  discriminators  -  thus  enabling  the  source  selection  decision  while 
fostering  an  impartial  and  comprehensive  evaluation  of  offerors’  proposals  and  selection  of  the 
proposal  representing  the  best  value  to  the  Government. 


ODUSD  (A&T)  Systems  and  Software  Engineering/Enterprise  Development 

ATL-ED@osd.mil 


14 


Systems  Engineering  Should  be  Integrated  in  All  Source  Selection  Factors 


EVALUA  TION  FA  CTORS 

•  Cost* 

•  Quality  of  Product* 

•  Past  Performance* 

•  Technical 

e.g.,  ILS,  excellence 

•  Management  Capability 

e.g.,  Personnel  qualifications 

•  Small  Business 

•  Mandatory  Factors  (FAR  Part  15) 


Source 

Selection 

Authority 


Contracting 
Officer  (CO) 


Advisor 


Source  Selection  Advisory 
Council 


Source  Selection  Evaluation 
Board  (SSEB) 


i 


•  sow 

•  Technical  Solution 

•  SEP 

•  Technical  Supporting 
Data 


•  Technical  /  •  Past  Performance 

Management  Integration  Criteria 

•  SOW  •  Past  Performance 

•  SEp  Questionnaire 

•  IMP  /  IMS 


•  Systems  Engineering  Costs 

•  WBS 


•  System  Performance 

Specification  * Referenced  sections  expand  the  topics 


Figure  2-3  Typical  Source  Selection  Organization  and  Factors 

An  offeror’s  proposal  must  respond  to  all  of  the  requirements  of  the  RFP.  [Note: 
Proposal  may  still  not  be  successful,  i.e.,  win  the  award].  However,  the  quality  of  the  proposal 
has  a  direct  correlation  to  the  clarity  and  completeness  of  the  Government’s  requirements  in  the 
RFP.  [Note:  Any  ambiguities  in  the  solicitation  will  be  held  against  the  Government  in  the  event 
of  a  dispute].  The  Government  should  assign  its  best  personnel  to  the  pre-solicitation  team  and 
the  source  selection  team.  The  source  selection  team  will  be  exercising  their  judgment  and 
critical  thinking  when  making  a  selection,  and  this  is  best  served  using  experienced  personnel 
that  have  domain  experience,  technical  expertise,  specifically  SE  and  other  specialty  areas  noted 
above,  and  program  knowledge.  It  may  be  necessary  to  train  some  of  the  team  in  the  source 
selection  process  in  more  detail  than  provided  herein. 
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3  REQUEST  FOR  PROPOSAL  AND  SOURCE  SELECTION 

The  RFP  includes  the  terms  and  conditions  that  will  be  in  the  final  contract.  The  FAR 
subpart  15.204,1  specifies  the  format  and  content  of  RFP  solicitations  and  contracts.  The  RFP 
typically  includes  two  categories  of  documentation: 

•  Program  Documents:  Government  Roadmap  Schedule,  Incentive  Plan,  Government  SEP, 
ISP,  TRA,  TES/TEMP,  and  preliminary  SPS  are  examples  of  program  documents  which  may 
be  attached  to  the  RFP  or  available  in  a  “Bidders  Library.”  Other  documentation,  such  as 
ICD,  CDD,  other  JCIDS  documents,  COTS/GOTS  data,  FoS/SoS  interface  data,  and  reports 
from  previous  phases  of  the  program  are  also  typically  included  in  the  Offeror’s  Library. 
These  documents  provide  background  on  the  program  and  describe  the  Government’s 
management  and  technical  approach  to  the  system  acquisition.  [Note:  Several  of  these 
documents  are  required  for  Milestone  B  and  are  described  in  the  DAG  Chapter  41. 

•  RFP  Documents:  A  typical  RFP  includes  a  model  contract  with  any  special  clauses  (e.g., 
CLINs,  SOO  or  SOW,  CDRL),  Preliminary  WBS,  Evaluation  Factors  (Section  M),  and 
Instructions  to  Offerors  (Section  L).  The  RFP  (with  the  program  documents  referenced  in 
the  RFP)  defines  the  program  and  sets  the  basis  for  the  contract. 

The  following  subsections  address  guidance  that  could  be  considered  to  include  in 
Sections  C  and  J  and  Sections  L  and  M  of  an  RFP. 

3.1  Sections  C  and  J  of  the  RFP 

Section  C  (includes  Description/Specification/SOO  or  SOW)  of  the  RFP  contains  the 
description  of  the  products  to  be  delivered  or  the  work  to  be  performed  under  the  contract.  This 
section  typically  includes  the  Government’s  SOO  (or  SOW)  and  preliminary  system 
performance  specification.  Section  J,  List  of  Attachments,  lists  the  attachments  such  as  initial 
IMP,  Top  Level  Program  Schedule,  Government  SEP,  CDRLs,  and  Contract  Security 
Classification  Specification  (DD  Form  254). 

3.2  Sections  M  and  L  of  the  RFP 

Please  note  that  we  have  selected  to  discuss  the  specifics  of  Section  M  before  L  since  that 
is  the  order  in  which  the  effort  is  needed.  Evaluation  Factors  are  defined  before  one  can 
complete  the  Instructions  to  Offerors.  In  order  to  accommodate  variations  among  the  Services’ 
source  selection  processes,  RFP  format  nuances,  and  differences  among  programs,  the  discussion 
of  Sections  M  and  L  is  segmented  into  four  general  topics:  i.e.,  Technical,  Management,  Past 
Performance,  and  Cost  (see  Figure  2-3).  The  technical  developers  of  these  sections  must  work 
closely  with  the  contracting  officer  to  ensure  compliance  with  appropriate  regulations.  The 
following  subsections  include  brief  discussions  of  each  topic  and  example  language  (in  shaded 
Tables)  that  can  be  tailored  for  program  RFPs  (or  other  type  of  solicitation).  [Note:  It  is 
important  to  remember  that  the  focus  of  this  guide  is  on  the  technical  elements  of  the  RFP,  and 
the  sample  items  must  be  integrated  with  the  rest  of  the  RFP  to  fit  the  overall  program  strategy 
and  program  implementation  approach]. 

Section  M  of  the  RFP  states  the  evaluation  factors  that  are  used  for  selecting  the 
contractor.  Section  M  should  be  carefully  structured  to  address  only  those  elements  determined 
to  be  discriminators  in  the  source  selection  to  select  the  best  proposal  with  acceptable  program 
risk.  The  most  effective  Section  M  evaluation  factors  are  measurable,  relevant  to  the  program, 
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traceable,  with  expected  differentiation  among  the  offers,  and  under  the  offeror’s  control. 
Section  M  should  not  contain  any  evaluation  factors  or  subfactors  for  which  there  is  not  a 
corresponding  request  for  proposal  information  in  Section  L.  Appendix  A  has  additional  tips  for 
program  teams  when  developing  Section  M. 

Section  L  of  the  RFP  instructs  the  offerors  on  how  to  structure  their  proposal  and  what 
should  be  included  in  each  proposal  section.  It  needs  to  clearly  identify  the  structure  and 
composition  of  each  volume  and  section  of  the  proposal  and  should  track  to  the  evaluation 
factors  in  Section  M. 

In  preparing  Sections  L  and  M,  be  aware  of  the  proposal  preparation  time  and  page 
limitations.  Ask  only  for  information  that  should  be  readily  available  to  offerors  and  that  is 
necessary  to  accomplish  the  source  selection  evaluation. 

Table  3-1  contains  a  list  of  SE  related  questions  to  help  the  team  develop  the  technical 
aspects  of  Section  M  and  Section  L. 

Table  3-1  Sample  Questions  for  Developing  Specific  SE  -Related  Criteria  and 
_ Instructions  for  Sections  M  and  L _ 

1 .  How  will  the  evaluation  team  establish  an  understanding  of  the  offerors’  technical 
approach? 

2.  How  can  the  evaluation  team  develop  confidence  that  the  offerors’  proposed  technical 
design  solutions  will  meet  all  technical  requirements,  including  operational 
performance  and  logistics/sustainment  requirements? 

3.  Is  the  technical  approach  implemented  within  performance,  cost,  and  schedule 
requirements? 

4.  How  will  the  evaluation  team  evaluate  the  SoS  or  FoS  interfaces  and  integration 
issues  on  the  program? 

5.  How  will  the  evaluation  team  establish  whether  the  specific  plans  for  implementing 
and  managing  the  technical  (i.e.,  SE)  and  technical  management  processes  are  based 
on  company  enterprise  processes?  Is  there  objective  evidence  of  the  capability  or 
maturity  of  these  processes  based  on  industry  best  practices?  How  will  they  be 
evaluated  for  consistency  and  compatibility  with  the  Government’s  technical  and 
management  processes  (as  defined  in  the  SEP)? 

6.  How  will  the  evaluation  team  determine  that  the  domain  experience,  past  performance,  and 
process  maturity  of  the  specific  project  team,  company  subgroup,  teammates,  and 
subcontractors  proposed  to  execute  the  work  directly  related  to  the  program  being 
bid? 

7.  How  will  the  evaluation  team  understand  whether  the  proposed  technical  solution  is 
adequately  supported  by  studies,  analyses,  modeling  and  simulations,  and 
demonstrations? 

8.  How  will  the  evaluation  team  evaluate  the  fidelity  and  appropriateness  of  modeling 
and  simulation  proposed  for  the  project,  and  how  will  it  be  validated? 

9.  How  will  the  evaluation  team  determine  whether  the  offeror's  proposed  IA  approach 
solution  meets  DoD  requirements?  Also  for  any  security  or  safety  engineering 
requirements. 

10.  How  will  the  evaluation  team  assess  the  maturity  and  application  of  the  offeror’s 
proposed  processes  in  the  proposal  risk  assessment? 


ODUSD  (A&T)  Systems  and  Software  Engineering/Enterprise  Development 

ATL-ED@osd.mil 


17 


1 1 .  How  will  the  evaluation  team  determine  that  the  risk  management  approach  proposed 
is  appropriate  for  the  program  being  bid  (e.g.,  consistent  and  compatible  with  the 
Government’s  risk  management  process). 

12.  How  will  the  evaluation  team  determine  that  technical  cost  and  resources  proposed  for 
the  program  are  reasonable  and  realistic  for  the  planned  program  approach? 

13.  How  will  the  evaluation  team  establish  that  the  offeror’s  proposed  schedule  is  realistic 
and  that  the  critical  path(s)  analysis  is  realistic? 


Oral  presentations  by  offerors  may  substitute  for  or  augment  written  information  (see 
FAR  §  15.102).  Use  of  oral  presentations  as  a  substitute  for  portions  of  a  proposal  can  be 
effective  in  streamlining  the  source  selection  process.  Oral  presentations  may  occur  at  any  time 
in  the  acquisition  process,  as  determined  by  the  CO  or  Source  Selection  Authority,  and  are 
subject  to  the  same  restrictions  as  written  information,  regarding  timing  (FAR  §  15.208)  and 
content  (FAR  §  15.306).  [Note:  Discussions  may  or  may  not  be  permitted  during  oral 
presentations].  Information  pertaining  to  areas  such  as  an  offeror’s  capability,  past  performance, 
work  plans  or  approaches,  staffing  resources,  transition  plans,  or  sample  tasks  (or  other  types  of 
tests)  may  be  suitable  for  oral  presentations. 

The  evaluation  team  may  include  a  matrix  in  the  RFP  that  correlates  Section  L  to  Section 
M  so  that  it  is  clear  what  portions  of  the  proposal  are  expected  to  contain  information  used  to 
evaluate  each  Section  M  evaluation  factors.  It  may  also  be  appropriate  to  develop  a  matrix  that 
includes  other  RFP  documents. 

The  next  sections  present  technical  example  items  for  inclusion  in  sections  M&L  of  the 
RFP  as  they  relate  to  the  three  key  evaluation  factor  areas  (i.e.,  Technical,  Management,  and  Past 
Performance).  Additionally,  we  address  overall  Proposal  Evaluation,  Cost  Factor  Evaluation, 
and  Risk  Assessment  Evaluation. 

3.2.1  Technical  Factor  Evaluation 

The  core  of  the  technical  evaluation  centers  on  the  offeror’s  system  performance 
specification,  the  description  of  the  technical  solution,  and  any  supporting  data  related  to  trade 
studies,  analyses,  modeling,  and  simulations  that  have  been  requested  in  Section  L.  [Note: 

Recall  we  present  section  M  (Evaluation  Factors)  examples  before  section  L  (Instructions  (e.g., 
Proposal  Content)  for  Offerors)  examples  due  to  precedence  in  the  determination.] 

3.2. 1.1  Technical  Solution  and  Technical  Supporting  Data 

An  offeror’s  technical  solution,  in  response  to  the  SOW  and  other  identified 
requirements,  will,  in  part,  be  based  on  analyses  that  are  based  on  technical  supporting  data  and 
resulting  performance  specifications.  These  topics  are  discussed  below. 

There  are  two  general  types  of  technical  data  requested  in  most  RFPs.  First,  there  is  the 
description  of  the  proposed  technical  solution  and  resulting  performance  as  it  relates  to  the 
Government’s  requirements.  [Note:  A  discussion  of  the  specific  technical  data  that  describes  the 
offeror’s  product  offering  is  not  addressed  here  since  it  is  unique  to  each  program].  Table  3-2 
and  Table  3-3  contain  sample  items  for  inclusion  in  Sections  M  and  L,  respectively,  for  the 
supporting  technical  data.  The  second  type  of  data  includes  trade  studies  and  analyses,  including 
modeling  and  simulation  results,  that  provide  substantiating  data  showing  not  only  the 
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performance  but  also  the  extent  and  scope  of  alternative  solutions  considered  before  arriving  at 
the  proposed  technical  solution  and  specification.  Often  “why”  something  was  discarded  is  as 
important  as  “what”  was  selected. 

Table  3-2  Sample  Evaluation  Criteria  for  Technical  Solution  and 
_ Technical  Supporting  Data _ 

The  technical  solution  and  technical  supporting  data  factor  (subfactor)  is  satisfied  when 

Offeror’s  proposal  demonstrates: 

1.  The  Offeror  has  conducted  a  series  of  trade  studies,  analyses,  and  modeling  and  simulations 
that  systematically  evaluated  the  range  of  alternatives  leading  to  a  preferred  technical 
solution.  The  results  support  the  technical  and  program  requirements  and  validate  the 
proposed  configuration  and  the  corresponding  performance  in  the  system  specification. 

2.  The  trade  study  process  was  uniformly  and  consistently  applied  and  followed  the  Offeror’s 
documented  corporate  enterprise  processes. 

3.  Trade  study  and  decision  criteria  addressed  the  critical  cost,  schedule,  technology,  risk,  and 
performance  requirements  (including  operational  and  sustainment)  and  other  considerations 
for  the  program  with  a  high  degree  of  confidence 


Table  3-3  Sample  Proposal  Content  Requirement  for  Technical  Solution  and 

_ Technical  Supporting  Data _ 

The  Offeror  shall  provide  a  summary  of  the  trade  studies  and  analyses  accomplished  to  arrive 

at  the  proposed  technical  solution.  The  Offeror  shall: 

1 .  Describe  the  trade  study,  analysis,  and  modeling  and  simulation  processes  implemented  to 
arrive  at  the  proposed  technical  solution;  explain  the  level  of  fidelity  of  the  models  and 
simulations  to  support  accurate  and  reliable  results. 

2.  Provide  a  summary  of  the  trade  studies,  demonstrations,  and  analyses  results  that  support 
the  proposed  technical  solution  and  program  technical  approach. 

3.  Provide  a  description  of  the  trade  study  evaluation  criteria,  how  they  relate  to  the  key 
performance  requirements  and  constraints  for  the  program,  and  the  planned  technical 
approach  addressed  in  the  contractor’s  integrated  SEP.  The  data  shall  address  the  range  of 
alternatives  considered  and  the  important  results  that  support  the  technical  decisions  and 
the  program  technical  approach.  If  the  contractor  plans  to  mature  a  technology,  back  up 
plans  should  be  assessed  as  well  as  risk  mitigation  planning. 


3.2.1.2  System  Performance  Specification  (SPS) 

A  preliminary  SPS  is  included  in  Section  C  of  the  RFP.  This  specification  defines  the 
Government’s  performance  requirements  for  the  system.  The  offeror  responds  with  a  SPS  in 
their  proposal  that  is  to  be  in  the  contract.  Table  3-4  and  Table  3-5  contain  sample  items  for 
inclusion  in  Sections  M  and  L,  respectively,  for  the  system  performance  specification. 
Remember  we  are  using  an  SOO  or  SOW  for  an  RFP  as  the  nominal  example  solicitation 
information.  These  can  be  tailored  and  modified  as  appropriate  for  other  solicitation  packages. 
The  offeror’s  specification  includes  the  Government  requirements  plus  any  derived  requirements 
necessary  to  describe  the  system  level  performance.  It  may  include  allocation  of  requirements 
and  should  include  corresponding  verification  requirements.  The  SPS  should  not  include  SOW 
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language,  tasks,  guidance,  or  data  requirements  but  should  reference  necessary  industry  and 
approved  military  specifications  and  standards. 

_ Table  3-4  Sample  Evaluation  Criteria  for  System  Performance  Specification 

The  Offeror’s  system  performance  specification  will  be  evaluated  in  conjunction  with  the 

proposed  technical  solution  based  on  the  following  criteria: 

1 .  Specification  includes  the  key  requirements  and  functionality  identified  in  the  RFP’s 
preliminary  system  performance  specification. 

2.  Performance  (including  logistics/sustainment/support)  requirements  are  quantifiable  and 
testable  and/or  verifiable. 

3.  Objective  values  (goals)  are  clearly  identified  and  distinguished  from  firm  requirements. 

4.  The  operational  and  support  environment  is  described  and  defined. 

5.  Environmental  design  requirements  are  specified. 

6.  Functional,  electronic,  physical,  hardware,  and  software  interfaces  for  the  system  are 
included. 

7.  System  FoS  and  SoS  interoperability  and  interface  requirements  are  established  (both 
physical  and  functional).  Considers  Open  Systems  and  Modularity  standards. 

8.  Appropriate  use  of  Government  and  industry  specifications,  standards,  and  guides. 

9.  Verification  approaches  for  all  system  performance  and  sustainability  requirements 
included  in  the  specification  are  complete  and  appropriate. 

10.  The  specification  does  not  include  unnecessary  requirements  and  language  (e.g.,  SOW 
tasks,  data  requirements,  and  product  or  technical  solution  descriptions). 


_ Table  3-5  Sample  Proposal  Content  for  System  Performance  Specification _ 

The  Offeror  shall  propose  a  System  Performance  Specification  that  meets  the  Government 
minimum  requirements.  The  specification  should  be  performance  based  and  address  the 
allocation  of  Government  performance  requirements  plus  any  derived  requirements  necessary 
to  describe  the  performance  of  the  integrated  system  solution.  Elements  to  be  addressed  in  the 
System  Performance  Specification  include: 

1 .  Accurate  and  complete  understanding  of  the  performance  and  support  requirements  in  the 
Government’s  preliminary  system  performance  specification  included  in  the  RFP. 

2.  Derived  requirements  necessary  to  document  the  system  performance  and  sustainability 
that  will  govern  the  design,  development,  and  test  program. 

3.  Identified  and  documented  system-level  operational,  physical,  and  functional  interfaces  that 
define  the  program  external  interfaces  and  constraints.  SoS  and  FoS  interoperability  and 
interface  requirements  are  included  for  both  physical  and  functional  interfaces.  Include 
considerations  for  Open  Systems  design. 

4.  A  verification  section  to  the  specification  that  delineates  the  approach  to  verifying  all 
performance  and  support  characteristics. 

5.  A  cross-reference  matrix  showing  the  tracking  of  Government  performance  requirements  to 
the  Offeror’s  proposed  system  performance  specification  (i.e.,  traceability).  The 
specification  should  be  structured  for  the  proposed  system  solution  and  not  restricted  by  the 
structure  of  the  Government’s  preliminary  system  performance  specification.  Include 
cross-reference  to  verification  methods. 
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3.2.2  Management  Factor  Evaluation 

The  sixteen  technical  management  and  technical  processes,  as  defined  in  the  DAG  $  4.2) 
are  as  follows: 


Technical  Management  Processes 

Decision  Analysis 
Technical  Planning 
Technical  Assessment 
Requirements  Management 
Risk  Management 
Configuration  Management 
Data  Management 
Interface  Management 


Technical  Processes 

Requirements  Development 

Logical  Analysis 

Design  Solutions 

Implementation 

Integration 

Verification 

Validation 

Transition 


These  processes  are  normally  evaluated  using  a  combination  of  the  offeror's  proposal 
documents.  An  offeror  is  expected  to  define  a  tailored,  as  appropriate,  set  of  technical  and 
management  processes,  usually  based  on  its’  own  set  of  mature  enterprise  processes.  These 
processes  are  usually  correlated  with  industry-wide  recognized  standards  and  best  practices.  One 
well  known  approach  is  based  the  Capability  Maturity  Model  Integration  (CMMI),  which  has 
been  particularly  useful  in  process  improvement  initiatives.  The  acquisition  evaluation  team  is 
cautioned  that  there  is  risk  in  accepting  the  applicability  of  an  organizations’  “CMMI  maturity 
(or  capability)  level  rating”  to  future  program  team’s  and  efforts.  Future  performance  is  driven 
by  a  large  spectrum  of  issues  such  as  specific  suppliers/vendors  and  compatibility  of  their 
respective  corporate  processes,  interaction  of  different  corporate  units  within  and  across 
suppliers,  the  amount  of  new-hires  versus  existing  staff  that  will  be  assigned  to  the  contract, 
timing  and  intensity  of  training,  for  all  team  members,  applicability  of  domain-specific 
knowledge  as  a  performance  factor,  and  the  extent  with  which  corporate  processes  will  be 
applied  to  the  new  work. 

In  this  guide,  suggested  technical  management  Section  M  evaluation  factors  are  presented 
in  an  integrated  example  (see  Table  3-6).  These  factors  will  correlate  with  appropriate  samples 
prepared  individually  for  proposal  content  in  Tables  3-7  to  3-10. 
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_ Table  3-6  Sample  Integrated  Evaluation  Factors  for  Technical  Management _ 

This  factor  (sub factor)  is  met  when  the  Offeror’s  proposal  demonstrates: 

1 .  The  program  tasks  in  the  SOW  are  fully  identified  and  include  the  technical  tasks. 

2.  Technical  planning  is  complete  and  supports  implementation  of  the  program’s  technical 
approach  and  accomplishment  of  the  requirements  and  objectives  contained  in  the  RFP. 

3.  Technical  and  technical  management  processes  are  implemented  across  the  program  team, 
using  appropriate  and  adequate  tools. 

4.  The  Offeror  has  implemented  a  technical  baseline  approach  (functional,  allocated,  and 
product  baselines)  that  support  the  program’s  technical  approach.  Data  and  software  rights 
are  clearly  explained. 

5.  Technical  processes  are  mature  and  stable  and  represent  the  Offeror’s  application  of 
corporate  enterprise  processes  and  lessons  learned. 

6.  Approach,  tasks,  processes,  and  procedures  are  flowed  down  to  the  subcontractors, 
vendors,  and  lowest  level  suppliers,  as  appropriate. 

7.  A  trained  workforce  (familiar  with  the  processes,  practices,  procedures,  and  tools)  is 
available  and  in  place  to  ensure  accomplishment  of  the  work. 

8.  Required  professional  certifications  (such  as  IA  required  by  DoDD  8570. 1)  are  held  by 
offered  personnel. 

9.  Technical  events  are  included  in  the  IMP/IMS  and  reflect  the  technical  approach. 

10.  The  IMP  narratives  include  the  technical  and  technical  management  processes  and  sub¬ 
processes  (as  appropriate). 

11.  The  IMS  clearly  indicates  the  program’s  critical  path(s)  and  has  acceptable  schedule  risk. 

12.  Technical  reviews  are  identified;  explicit  entry  and  exit  criteria;  participation  established; 
and  have  the  timing  and  frequency  necessary  to  monitor  and  control  technical  baseline 
maturity  and  risk  mitigation. 

13.  There  is  a  single  technical  authority  that  is  responsible  for  program  technical  direction. 

The  lines  of  responsibility  and  authority  are  clearly  established. 

14.  Key  personnel  are  assigned  and  personnel  resources  identified. 

15.  The  role  of  the  Government  (program  office,  supporting  Government  organizations,  and 
user)  along  with  the  key  subcontractors  has  been  identified. 

16.  Program  IPTs  are  established  that  involve  program  participants  and  stakeholders  for  all 
Life  Cycle  phases  and  identify  roles  and  responsibilities. 

17.  Program-specific  plans  represent  a  sound  integrated  technical  approach.  The  plans  are 
flowed  down  to  the  teammates,  subcontractors,  vendors,  and  lowest  level  suppliers  on  the 
program.  The  planning  is  integrated  across  the  SOW,  SEP,  IMP/IMS,  and  other  program 
management  plans  and  processes  to  support  critical  path  analysis,  EVM,  and  risk 
management. 

18.  The  Offeror’s  SEP  should  thoroughly  document  the  Offeror’s  technical  approach  to  the 
integrated  set  of  program  requirements,  technical  staffing  and  organization  planning, 
technical  baseline  management  planning,  technical  review  planning,  and  the  integration 
with  overall  management  of  the  program.  It  should  clearly  show  how  it  is  integrated, 
consistent,  and  aligned  (but  more  detailed)  with  respect  to  the  Government’s  SEP. 

19.  Proactive,  disciplined  SE  technical  management  process  leading  indicators  that  provide  a 
picture  of  future  course  that  a  program  is  likely  to  follow.  The  indicators  should  be 
measurable,  map  to  incentive  strategies  and  result  in  early  identification  and  mitigation  of 
risk. 
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More  specific  technical  suggestions  for  individual  proposal  content  (per  Instructions  in 
Section  L)  examples  are  presented  for  each  of  the  following  subsections  of  a  typical  proposal, 

i.e.,  SOW,  SEP,  IMP/IMS,  and  IMS  Narratives  for  the  Management  Volume. 

3.2.2. 1  Offeror’s  Statement  of  Work  (SOW) 

The  offeror  responds  to  the  RFP  with  a  SOW  [Note:  also  referred  to  as  the  Contractor’s 
SOW  (CSOW)]  that  addresses  the  objectives  stated  in  the  Government’s  SOO  or  SOW,  other 
sections  of  the  RFP,  and  derived  requirements  based  on  the  offeror’s  approach.  The  SOW 
defines  tasks  and  activities  that  the  offeror  proposes  to  execute  under  the  contract.  The  technical 
approach  relies  heavily  on  contractor’s  processes  and  practices,  and  the  SOW  should  address  the 
application  of  the  processes  during  the  design,  development,  test,  manufacture,  delivery,  and 
sustainment,  as  applicable  to  the  program.  It  is  generally  not  the  intent  to  incorporate  the 
contractor’s  detailed  processes  and  practices  into  contract.  Since  the  SOW  will  become  a 
baseline  for  the  resulting  contract,  it  should  be  thoroughly  reviewed  to  ensure  it  adequately 
addresses  all  the  work  to  be  accomplished  during  the  program.  Table  3-7  provides  sample 
proposal  content  to  be  placed  in  Section  L  language  for  the  SOW. 

Table  3-7  Sample  Technical  Proposal  Content  for  SOW 

The  Offeror  shall  provide  a  SOW  to  be  included  in  the  negotiated  contract.  (In  the  case  where 

the  Government  provided  a  SOW  with  the  RFP,  the  Offeror  may  propose  changes;  however, 

each  change  shall  be  accompanied  by  supporting  rationale  demonstrating  why  accepting  the 

proposed  change  is  in  the  Government’s  interest.)  The  SOW  shall: 

1.  Describe  the  technical  work,  tasks,  and  activities  to  be  accomplished  on  the  program  that 
reflect  the  technical  approach  to  the  program  as  described  in  the  Offeror’s  SEP. 

2.  Reflect  use  of  technical  and  technical  management  processes  across  the  program  that  are 
critical  for  program  success. 

3.  Address  the  technical  baseline  management  process  (functional,  allocated,  and  product 
baselines). 

4.  Address  delivery  of,  and  describe  the  Government’s  rights  in,  all  required  technical  data 
and  computer  software. 

5.  Provide  for  event-based  technical  reviews  with  entry  and  exit  criteria  and  independent 
SME  participation. 

6.  Provide  for  technical  planning  and  the  Offeror’s  integrated  SEP  updates  and  continuous 
process  improvement  consistent  with  corporate  improvements  and  program  needs.  Explain 
how  performance  requirements  will  be  verified. 

7.  Discuss  the  Offeror’s  SOW  as  structured  for  the  proposed  system  solution  and  not 
restricted  by  the  structure  of  the  Government’s  SOO  or  SOW.  This  is  correlated  and 
consistent  with  the  integrated  WBS,  IMP,  IMS,  and  EVMS. 


3.2.2.2  Offeror’s  Systems  Engineering  Plan  (SEP) 

The  offeror  should  consider  the  Government’s  planned  technical  management  strategy 
and  approach,  as  reflected  in  the  Government  SEP,  to  prepare  their  proposals  including  their  own 
integrated  SEP.  As  a  result,  many  elements  of  the  Government’s  SE  strategy  will  be  reflected 
within  the  contract  documents  (e.g.,  SEP,  SOW,  CDRL,  IMP,  IMS,  and  WBS).  It  is  suggested 
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that  instructions  for  the  offeror’s  SEP  (see  Table  3-8)  in  Section  L  include  the  requirement  for 
the  offerors  to  provide  a  matrix  that  correlates  the  Government  SEP  with  the  offeror’s  SEP, 
contractual  documents,  and  other  volumes  of  the  proposal  where  SEP  amplifying  information  is 
discussed. 


_ Table  3-8  Sample  Technical  Proposal  Content  for  SEP _ 

The  Offeror  shall  submit  a  SEP  that  describes  their  integrated  technical  approach  to  the 

program.  The  Offeror’s  SEP  shall  include: 

1.  The  entire  contract  -  related  requirements,  tasks,  activities,  and  responsibilities  included  in 
the  Government  SEP,  as  they  relate  to  this  solicitation,  shall  be  in  alignment.  If  the  Offeror 
elects  to  change  or  revise  the  planned  technical  approach  described  in  the  Government’s 
SEP,  the  rationale  for  the  change  shall  be  provided. 

2.  A  description  of  the  key  technical  and  technical  management  processes.  Provide  Offeror’s 
(and  teammates,  subcontractors,  etc.)  plans  for  continued  process  improvement. 

3.  Flow  down  of  technical  and  technical  management  plans  and  processes  to  the 
subcontractors  or  teammates,  and  how  they  participate  in  the  processes. 

4.  An  event-based  program  plan  (correlated  and  consistent  with  the  IMP)  for  the  efforts 
involved  with  the  design,  development,  test,  production,  and  sustainment,  including 
planned  block  upgrades,  technology  insertion,  etc. 

5.  Planned  technical  reviews  with  entry  and  exit  criteria  and  independent  SME  participation. 

6.  Identity  of  the  technical  authority,  stakeholders,  and  functional  technical  authorities  on  the 
program  and  the  limit  and  scope  of  their  responsibilities. 

7.  A  description  of  the  technical  organization  within  the  program  IPT  structure  identifying 
roles  and  responsibilities,  key  personnel,  and  technical  staffing  requirements.  Identify  the 
primary  participants  within  each  IPT  and  the  supporting  participants  to  include  the 
Government  and  subcontractors.  Include  a  summary  of  the  principle  products  of  the  IPTs. 
Include  a  description  of  technical  working  groups  (or  IPTs)  with  roles,  responsibilities,  and 
proposed  participants  (e.g.,  Interface  Working  Group,  T&E  Working  Group,  and 
Technology  Roadmap  Working  Group). 

8.  Integration  of  the  technical  and  technical  management  processes  with  IMP/IMS  and  EVM 
processes. 

9.  A  summary  description  of  the  proposed  set  of  program  planning  and  specific  plans  such  as 
SEP,  TEMP,  ISP,  Software  Development  Plan,  PSP,  Risk  Management  Plan,  etc.,  to  ensure 
consistency  and  completeness. 

10.  A  matrix  that  correlates  the  Government  SEP,  with  the  Offeror’s  integrated  SEP,  proposed 
contractual  documents  (SOW,  IMP/IMS,  WBS),  and  other  volumes  of  the  proposal  where 
SEP  amplifying  information  is  discussed. 


3.2.2.3  Integrated  Master  Plan/Integrated  Master  Schedule  (IMP/IMS) 

The  RFP  should  contain  a  Government  Roadmap  Schedule  (IMP/IMS  §  3.1.1)  that 
depicts  the  major  program  elements  and  key  milestones,  such  as  contract  award,  event-based 
technical  reviews,  technical  baseline  development  and  lock  down,  developmental  test  and 
evaluation  (DT&E),  operational  test  and  evaluation  (OT&E),  production  or  long  lead  decisions, 
and  system  delivery.  Typically,  most  of  the  events  contained  in  the  program  IMP  are  based  on 
technical  activities  and  normally  include  the  SDD  items  that  are  described  in  the  DAG  §  4.3.3. 
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The  IMP  and  IMS  should  clearly  demonstrate  that  the  program  is  executable  within 
schedule  and  cost  constraints  and  with  acceptable  risk.  They  should  provide  a  functionally- 
integrated  picture  of  the  proposed  program  with  a  direct  correlation  between  the  event-driven 
activities  in  the  IMP/IMS  and  the  SOW  and  CWBS  planned  technical  approach  documented  in 
the  SEP  (see  Table  3-9).  Thus,  the  IMP/IMS  and  SEP  are  key  elements  during  the  proposal 
evaluation  and  source  selection.  Finally,  the  IMP/IMS  must  be  correlated  and  consistent  with  the 
defined  CWBS  and  EVMS. 

Table  3-9  Sample  Technical  Proposal  Content  for  IMP/IMS 

The  Offeror  shall  submit  an  IMP  that  is  structured  as  an  event-based  schedule.  Technical 
reviews  applicable  to  the  contracted  event  shall  be  included  as  events.  The  maturity  of  the 
technical  performance  approach  as  well  as  status  of  risk  action  plans  will  be  reviewed.  The 
IMP  shall  include  events,  accomplishments  that  tie  to  these  events  and  completion  criteria  for 
each  accomplishment  for  the  total  contracted  effort.  Any  block  upgrades  and  technology 
insertions  identified  as  options  for  this  contracted  effort  shall  also  be  included. 

The  Government  Top  Level  Program  Plan  and  Schedule  and  SEP,  included  in  this  RFP, 
define  a  minimum  set  of  technical  events  to  be  included  in  the  proposed  IMP.  Criteria  for 
entry  into  any  technical  event  will  be  tied  to  the  associated  accomplishment  completion 
criteria.  The  Offeror  may  include  additional  technical  events  with  associated  accomplishments 
and  completion  criteria  or  more  rigorous  completion  criteria  as  required. 

The  IMS  shall  include  the  program  schedule  with  technical  tasks  and  activities  necessary 
to  complete  the  work  effort  scoped  within  the  IMP.  The  program’s  critical  path(s),  based  on 
critical  path  analyses,  shall  be  identified  in  the  IMS.  The  results  of  a  schedule  risk  assessment 
shall  be  presented  which  reflect  acceptable  schedule  risk.  [Note:  It  is  not  uncommon  for  the 
Government  to  specify  a  minimum  schedule  risk  value,  such  as,  80  percent  probability  of 
achieving  the  key  event(s)  with  80  percent  confidence.]  If  the  assessment  concludes  that 
schedule  risk  is  unacceptable,  the  Offeror  should  adjust  the  schedule  or  include  risk  mitigation 
efforts. 

Finally,  the  IMS  association  with  the  EVMS  shall  be  summarized;  and  will  be  addressed 
in  the  Cost  Volume  also. 


Some  programs  may  require  a  Process  Narrative  Section  with  an  IMP.  Sample  text  is 
provided  in  Table  3-10.  [Note:  A  technical  narrative  may  not  be  necessary  since  the  offeror’s 
required  integrated  SEP  will  probably  cover  the  appropriate  narrative  information  (IMP/IMS  § 
333).] 


_ Table  3-10  Sample  Proposal  Content  for  IMP  Narratives _ 

The  Offeror  shall  include  within  the  IMP  process  narratives  a  brief  synopsis  of  the  Offeror’s 
systems  engineering  and  technical  processes  considered  essential  for  program  success.  The 
narratives  shall  reference  the  Offeror’s  corporate  processes  and  best  practices  and  indicate  how 
they  will  be  applied  and  tailored  to  the  specific  program. 
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3.2.2.4  Other  Technical  Management  Criteria 

The  Management  Volume  can  also  be  used  to  highlight  specific  technical  management 
topics  that  are  discriminators  for  the  source  selection.  These  topics  are  those  the  Government 
seeks  added  information  or  data  for  the  evaluation  over  and  above  what  has  been  addressed  in 
the  previous  sections  on  the  SOW,  SEP,  and  IMP/IMS  (see  Table  3-11).  These  criteria  should 
not  be  used  to  systematically  address  all  technical  and  management  processes  to  be  used  on  the 
program  (these  should  have  been  included  in  the  SEP  or  IMP  narratives).  This  is  why  it’s 
important  that  an  experience  systems  engineer  also  be  on  the  Management  Factor  evaluation 
team. 


_ Table  3-11  Sample  Technical  Proposal  Content  for  Other  Management  Criteria 

The  Offeror  shall  submit  a  Management  Volume  that  describes  the  key  technical  processes  and 

how  they  are  integrated  with  the  other  management,  financial,  and  functional  processes. 

Examples  of  technical  topics  for  special  emphasis  in  the  Management  Volume  include: 

1.  FoS  and  SoS  issues  and  integration  approach  and  net-centric  operation  requirements. 

2.  Program  organization,  roles  and  responsibilities  of  IPTs,  and  specifically  the  SEIPT.(see  also 
Table  3-8,  #7) 

3.  The  electronic  or  virtual  program  approach  including  data  and  information  exchange  (see 
also  Table  3-7  #2  and  Table  3-8  #2  and  #8). 

4.  Discussion  of  risk  management  and  configuration  management  approaches. (  see  also  Tables 
3-7  #2  and  #3,  3-8  #2,  #3,  and  #9) 

5.  Facilities  for  design,  development,  and  testing. 

6.  M&S  processes,  M&S  fidelity,  special  facilities,  M&S  support  tools,  and  past  applications. 
[Note:  this  is  a  “specialty”  SE  example]  (see  also  Table  3-7  #2) 

7.  Resumes  and  past  experience  for  the  technical  leadership  and  key  technical  personnel  (see 
also  Table  3-8  #7). 

8.  Discussion  of  program  staffing  requirements,  surge  capability,  personnel  recruiting,  and 
program  ramp-up  activities  at  program  start  (see  also  Table  3-8  #7). 

9.  Discussion  of  special  engineering  requirements  and  processes  such  as,  security  engineering, 
safety,  flight  certification,  survivability/vulnerability,  human  systems  integration  (HSI), 
interoperability,  spectrum  considerations,  information  system  security  (e.g.,  IA)  (see  also 
Tables  3-7  #1,  and  3-8  #1). 

10.  Obsolescence  requirements  growth  plans  and  technology  insertion  upgrade  plans  (see  also 
Tables  3-7  #1  and  3-8  #4). 


3.2.3  Past  Performance  Factor  Evaluation 

The  Government  uses  the  past  performance  record  to  demonstrate  that  the  offeror 
possesses  the  skill  and  experience  to  perform  well  and  achieve  the  performance  requirements  on 
the  new  contract.  An  offeror  with  experienced  personnel  in  the  applicable  domain,  bolstered 
with  a  credible  past  performance  record,  should  result  in  better  contract  performance  (e.g.,  lower 
risk  and  cost  while  still  achieving  the  user’s  performance  requirements)  (FAR  §  42.15,  and  FAR 
§  15.305  as  supplemented).  The  source  selection  team  should  relate  each  offeror’s  past 
performance  record  to  the  Source  Selection  Authority  (SSA)  in  a  manner  that  facilitates  an 
integrated  assessment  with  the  remainder  (e.g.,  Technical,  Management)  of  the  offeror’s 
proposal. 
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While  there  is  a  direct  relationship  between  past  performance  and  the  technical  factors, 
each  of  these  evaluations  must  stand  on  its  own  merit,  is  reported  separately,  and  cannot  change 
the  other.  For  example,  the  technical  evaluation  on  software  could  show  no  major  weaknesses 
while  the  past  performance  evaluation  could  reveal  unsatisfactory  past  performance. 

It  is  recommended  that  the  past  performance  evaluation  group  start  with  the  Past 
Performance  Information  Retrieval  System  (PPIRS)  for  past  performance  information.  Most 
past  performance  assessments  utilize  a  questionnaire  that  requests  specific  information  about  an 
offeror’s  performance  from  their  previous  customers.  The  respondent  may  be  asked  to  provide  a 
rating  ranging  from  “Exceptional”  to  “Unacceptable”  or  “N/A”  and  provide  a  brief  explanation 
of  the  rating.  This  allows  for  the  questionnaire  to  be  filled  out  quickly  and  easily,  but  the  key  to 
a  useful  assessment  is  the  evaluation  of  respondents  ’  comments  and  rationale  for  the  rating. 
Another  means  to  collect  the  data  is  for  past  performance  evaluators  to  contact  the  respondents 
and  complete  the  questionnaire  via  a  discussion  or  interview.  The  DCMA  should  be  invited  to 
participate  in  this  source  selection  activity,  as  determined  by  the  CO  or  SSA. 

3.2.4  Proposal  Evaluation 

The  proposal  must  be  responsive  to  the  Section  L,  Instructions  to  Offeror.  The  SSEB 
(see  Figure  2-3)  can  only  use  the  Section  M  Evaluation  Factors  included  in  the  RFP.  No  other 
criteria  can  be  used  in  the  source  selection  process,  just  as  no  outside  material  other  than  that 
submitted  with  the  proposal  can  be  used  (except  for  Past  Performance).  The  SSEB  will  be 
exercising  their  judgment  and  critical  thinking  when  making  a  selection  and  this  is  best  served 
using  experienced  personnel  that  have  domain  experience,  technical  expertise,  and  program 
knowledge.  Appendix  A  contains  additional  tips  that  can  aid  in  the  evaluation  of  the  technical 
(Table  A-l),  management  (Table  A-2),  and  past  performance  factors  (Table  A-3). 

3.2.5  Cost  Factor  Evaluation 

The  cost  evaluation  should  address  evaluation  of  cost  reasonableness,  realism,  and  risk. 
The  effective  and  useful  evaluation  of  cost  can  best  be  accomplished  when  it  is  supported  by 
technical  personnel  who: 

(1)  have  technical  knowledge  in  the  relevant  domain; 

(2)  have  past,  hands-on  experience; 

(3)  are  familiar  with  the  scope  and  objectives  of  the  program;  and 

(4)  recognize  the  interdependencies  of  cost,  schedule,  and  technical  performance. 

In  a  proposal,  the  Basis  of  Estimate  (BOE)  supporting  rationale  and  associated 
assumptions  should  be  based  upon  meaningful  analysis,  credible  historical  data,  past  experience, 
and  expert  judgment.  The  Government’s  most  probable  cost  relies  on  the  identification  of 
weaknesses  within  the  proposal  (e.g.,  inconsistencies  between  the  technical  approach  and  the 
assumptions  listed  in  the  BOE)  and  the  computation  of  adjustments  to  the  offeror’s  proposed  cost 
or  price.  Price  factors  for  commercial  services  or  products  are  also  addressed,  as  appropriate. 

The  technical  portion  of  the  cost  evaluation  tips  are  contained  in  Appendix  A  (Table  A-4). 


There  should  be  specific  and  comprehensive  two-way  communication  about  significant 
differences  between  the  offerors  proposed  costs  or  prices,  and  the  Government’s  most  probable 
cost  estimates  of  these  costs  or  prices.  The  goal  of  these  discussions  is  to  fully  understand  the 
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reasons  for,  and  the  magnitude  of,  the  differences  between  an  offeror’s  proposed  costs  or  prices 
and  the  Government  most  probable  cost  estimate,  including  key  cost  elements. 

3.2.6  Proposal  Risk  Assessment  Evaluation 

The  proposal  risk  assessment  is  typically  reported  at  the  factor  level,  i.e.,  technical  and 
management;  however,  there  is  an  option  to  report  the  risks  at  the  subfactor  level.  The  SSEB  has 
two  options  when  conducting  the  proposal  risk  assessment.  The  first  method  is  to  accomplish 
the  proposal  risk  assessment  for  each  factor  or  subfactor.  In  this  case  the  final  evaluation  of  the 
factor  would  have  two  components — a  factor  score  (usually  denoted  in  a  color  rating  if  used)  and 
a  proposal  risk  rating  (ranging  from  “high  risk”  to  “low  risk”). 

The  second  method  is  to  combine  the  factor  rating  and  proposal  risk  rating  together.  In 
this  case,  for  example,  a  blue  (“exceeds  standard”  color  rating)  might  be  lowered  to  a  green 
rating  if  it  involves  some  risk.  In  an  extreme  case,  a  blue  rating  might  be  lowered  to  yellow  or 
red  if  the  risk  is  determined  to  be  high.  In  both  cases  the  proposal  risk  assessment  essentially 
answers  the  following  question.  If  the  offeror  does  (or  delivers)  what  he  proposes,  what  is  the 
risk  that  he  will  not  succeed,  i.e.,  not  meet  key  performance  and  other  critical  requirements 
within  schedule  and  resource  constraints? 

This  assessment  establishes  the  risk  associated  with  the  offeror’s  proposed  program  to 
include  the  technical  approach,  technical  performance,  management  approach,  application  and 
integration  of  management  and  technical  processes,  program  schedule,  and  cost/resource 
allocations.  The  technical  portion  of  the  proposal  risk  evaluation  tips  are  contained  in  Appendix 
A  (Table  A-5). 
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4 


CONTRACT  EXECUTION 


During  the  first  few  weeks  after  contract  award  it  is  important  the  Government  and 
contractor  team  have  an  interactive,  face-to-face  meeting  and  that  the  technical  leaders  step 
forward  and  set  the  tone  for  the  program.  Three  important  program  activities  immediately  after 
contract  award  are  the  Post  Award  Conference  (see  Table  4-1  and  FAR  §  42.51.  the  Integrated 
Baseline  Review  (IBR)  (see  Table  4-2  and  also  The  Program  Managers’  Guide  to  the  Integrated 
Baseline  Review  (IBR)  Process  and  DAG  §11.3.1.3).  and  SEP  Integration  (see  Table  4-3), 

_ Table  4-1  Systems  Engineering  Tasks  during  Post  Award  Conference _ 

1.  Reinforce  the  importance  of  having  the  Government  and  contractor  engineering 
personnel  functioning  as  an  integrated  team,  while  recognizing  the  responsibilities  that 
inherently  reside  with  contractor  (executing  the  contract),  the  Government  Program 
Office  (program  leadership  and  contract  oversight),  the  user,  and  DCMA. 

2.  Review  the  program  technical  approach  and  the  plan  for  alignment  of  the  Government 
SEP  (included  in  the  RFP)  with  the  contractor’s  inputs  to  the  Government  SEP. 
Validate  technical  tasks  within  the  SOW. 

3.  Review  the  system  performance  specification  to  ensure  a  mutual  understanding  of  the 
functional  baseline. 

4.  Reinforce  the  importance  of  leveraging  the  contractor’s  domain  expertise  and 
implementing  the  contractor’s  “enterprise”  technical  and  technical  management 
processes  as  documented  in  the  proposal  SEP. 

5.  Review  and  establish  the  initial  set  of  metrics  and  measures  (the  baseline)  that  will  be 
used  to  monitor  and  control  the  program. 

6.  Review  risk  management  planning  and  the  Risk  Management  Plan,  if  applicable,  and 
the  baseline  of  the  program  risks.  [Note:  Program  risks  include  both  Government  and 
contractor  risks.]  Review  the  risk  mitigation  plans. 

7.  Review  plans  for  event-based  technical  reviews  (along  with  entry  and  exit  criteria  and 
independent  SME  participation)  documented  in  the  IMP  and  proposal  SEP;  review  the 
technical  tasks  and  products  resulting  from  the  IMS  tasks;  and  ensure  correlation  of 
the  technical  metrics  and  measures,  IMP/IMS,  and  the  EVMS  in  preparation  for  the 
Integrated  Baseline  Review  (IBR). 

8.  Review  and  discuss  the  issues  and  concerns  identified  during  source  selection  to 

ensure  they  are  understood  and  any  issues  are  resolved. _ 


_ Table  4-2  Technical  Tasks  during  the  IBR _ 

1 .  Review  critical  milestones  and  early  program  support. 

2.  Verify  the  technical  approach  of  the  program.  Ratify  the  entry  and  exit  criteria  for 
program  events  by  reviewing  the  events,  accomplishments,  and  criteria  in  the  IMP. 

3.  Establish  the  IMS  tasks  to  support  the  program.  Task  durations,  resources,  and 
interrelationships  should  be  reviewed  and  understood. 

4.  Review  the  risk  management  process,  establishing  the  baseline  and  mitigation  plans. 

5.  Verify  acceptance  of  the  integrated  Program  SEP.  Establish  the  plan  for  future 
updates. 

6.  Actively  participate  with  the  financial  personnel  to  establish  the  EVM  baseline. 

Verify  that  the  EVMS  is  certified. _ 
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Presuming  that  the  RFP  required  the  submittal  of  an  offeror’s  SEP,  then  the  actions  to 
consolidate  the  Government  and  offeror’s  SEPs  into  a  joint,  Program  SEP  should  be 
accomplished  immediately  after  contract  award  (see  Table  4-3). 

Table  4-3  Establishing  the  Integrated  Program  SEP 

The  following  general  approach  to  achieving  an  integrated  (i.e.,  aligned)  Program  SEP  is 
recommended: 

Immediately  after  contract  award,  the  entire  program  team  leadership  should  establish  an 
integrated  Program  SEP  to  reflect  both  the  Government  and  industry  efforts  on  the 
program.  This  integrated  Program  SEP  will  usually  be  two  documents  -  the  Government 
SEP  and  the  contractor  integrated  (the  latter  being  a  CDRL).  Together,  they  guide  all 
program  stakeholders  as  to  the  technical  aspects  of  the  program. _ 


The  recommended  approach  to  transition  the  Government  SEP  into  an  integrated 
Program  SEP  (Government  and  industry)  involves  a  continuum  of  activity  that  begins  during 
RFP  preparation  and  continues  through  source  selection,  contract  award,  and  initial  program  start 
up  activities  (see  Figure  4-1). 


Program  Systems  Engineering  Plan  -  Shared  Vision  of  the  Program’s  Technical  Approach 


RFP  Preparation 

•  Acquirer’s  Technical 
Approach  as  Documented 
in  Government  SEP 

•  Written  by  Program 
Manager,  Lead  Systems 
Engineer,  Lead  Tester, 
Lead  Logistician,  and  other 
SMEs 


•  Source  Selection 

•  Offeror’s  Proposed 
Technical  Approach 
based  on  Offeror’s 
integrated  SEP  and 
other  supporting 
technical  documents 

•  Evaluated  by  Source 
Selection  Evaluation 
Board 


•  Post-Award  Planning 

•  Program  Team’s  Technical 
Approach  as  Documented  in 
Program  SEP  and  related 
technical  documents 

•  Written  by  Program  Manager, 
Lead  Systems  Engineer,  Lead 
Tester  Lead  Logistician,  and 
other  SMEs  from  Government, 
Prime  Contractor,  Subs,  and 
Suppliers 


•  Execution 

•  Execute  the 
Technical  Approach 

•  Program  integrated 

SEP  updated  by 
Program  Team 


Figure  4-1  Establishing  an  Integrated  Program  SEP 

Although  this  guide  is  focus  particularly  on  solicitation  and  contract  award,  administering 
the  contract  throughout  the  contract  period  is  also  important.  From  the  program’s  perspective, 
the  Program  SEP,  and  supporting  documentation  (e.g.,  Risk  Management  Plan,  TEMP,  ISP),  is 
the  basis  to  monitor  and  control  the  program  (including  contractors)  activities  and  performance. 
DCMA  should  be  involved,  particularly  with  respect  to  FAR  §  42.302  on  contract 
administration.  The  following  are  particularly  relevant  to  SE  activities: 
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•  Perform  engineering  surveillance  to  assess  compliance  with  contractual  terms  for 
schedule,  cost,  and  technical  performance  in  the  areas  of  design,  development  and 
production. 

•  Evaluate  for  adequacy  and  perform  surveillance  of  contractor  engineering  efforts  and 
management  systems  that  relate  to  design  development,  production,  engineering  changes, 
subcontractors,  tests,  management  of  engineering  resources,  reliability,  maintainability, 
data  control  systems,  configuration  management  and  independent  research  and 
development. 

•  Review  and  analyze  contractor  proposed  engineering  design  studies;  submit  comments 
and  recommendations  to  the  CO. 

These  SE  activities  are  well  addressed  in  the  DAG’s  SE  technical  and  management 
processes,  particularly  Technical  Assessment  (see  also  Section  3.2.2  of  this  guide). 
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APPENDIX  A.  DEVELOPMENT  OF  SE  INPUT  TO  SECTIONS  M,  L,  AND  PROPOSAL 
EVALUATION 


Table  A-l  through  Table  A- 5  contain  sample  questions  that  can  aid  the  program  teams  in 
development  of  technical  aspects  to  include  in  Section  M  and  Section  L  for  the  RFP;  and  the 
subsequent  evaluation  of  proposals  during  the  source  selection. 

Table  A-l  Technical  Focus  for  the  Technical  Factor  Evaluation 

Technical  Factor  Reference  Sections  3.2.1  and  3.2.4 

1 .  Does  the  product  offering  (technical  solution)  meet  performance  and  sustainment 
requirements?  Does  it  exceed  the  requirements,  and  is  this  of  value  to  the  Government? 

2.  Does  the  product  reflect  the  required  special  design  considerations,  such  as,  MOSA, 
safety,  information  security,  net-centric  operations,  etc? 

3.  Are  all  the  critical  or  key  requirements  included  within  the  specification?  (Watch  for 
“parroting”  of  the  Government  requirements  without  regard  to  substantiating  evidence  in 
the  other  sections  of  the  proposal.  A  claim  of  performance  without  substantiating  data  is  a 
technical  risk.) 

4.  Are  the  goals  appropriately  identified  and  differentiated  from  firm  requirements?  (Goals 
do  not  have  much  standing  as  contract  performance  requirements.) 

5.  Are  specification  requirements  stated  in  performance  language?  Are  there  any  SOW  tasks 
or  data  deliveries  in  the  specification? 

6.  Is  the  specification’s  Verification  and  Test  Section  more  detailed  than  just  a  table 
reflecting  only  a  method  of  verification?  Is  there  a  one-to-one  correlation  with  the 
Performance  Requirements?  Is  the  test  section  consistent  with  the  engineering  and  test 
approach  documented  in  other  sections  of  the  proposal? 

7.  Are  the  system  interface  requirements  identified  and  documented?  Do  they  reflect  the 
requisite  SoS  and  FoS  interoperability  and  interface  requirements,  as  appropriate? 

8.  Do  the  analyses,  modeling  and  simulations,  and  trade  studies  support  design  decisions  and 
technical  approach  to  the  program?  Is  the  effort  comprehensive  (i.e.,  include  relevant 
solutions,  technologies,  and  alternatives)  and  address  the  areas  of  technical,  cost, 
schedule,  and  risk? 

9.  Does  the  technical  approach  address  all  phases  of  the  product  life  cycle  (i.e.,  TLCSM)  and 
effectively  employ  the  precepts  of  System  Operational  Effectiveness  (SOE)  and  System 
Design  and  Operational  Effectiveness  (SDOE)? 

10.  Are  the  resource/cost  estimating  factors  and  assumptions  for  technical  work  and  products 
supported  by  the  Offeror’s  domain  experience  and  past  performance? 
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_ Table  A-2  Technical  Focus  for  the  Management  Factor  Evaluation _ 

Statement  of  Work  Reference  3.2.2. 1  and  3.2.4 

1.  Does  the  SOW  cover  the  entire  scope  of  the  program,  including  the  requisite  technical 
tasks  and  activities?  Is  it  consistent  with  the  program  technical  objectives  in  the  SOO  or 
SOW? 

2.  Does  the  SOW  include  inappropriate  items  on  contract?  (For  example,  Technical  day-to- 
day  procedures  and  instructions  are  captured  in  excessive  detail  and  then,  as  they  mature 
during  the  program,  they  cannot  be  implemented  without  a  contract  change.)  The  goal  is 
to  secure  a  commitment  to  implementing  the  process,  not  controlling  detailed  procedures. 

3.  Does  the  SOW  identify  specific  IPTs  that  accomplish  the  tasks  or  include  dates  for  start  or 
completion  of  tasks?  The  dates  and  IPTs  are  identified  in  the  IMS. 

4.  Does  the  SOW  include  tasks  for  conducting  event-based  technical  reviews  consistent  with 
the  program  technical  and  support  approach  included  in  the  Offeror’s  SEP? 

5.  Are  all  the  appropriate  technical  management  processes  and  technical  processes  included? 

Systems  Engineering  Plan  Reference  3 .2.2.2  and  3.2.4 

1.  Does  the  Offeror’s  SEP  expand  and  refine  the  Government  SEP  provided  in  the  RFP?  Is  it 
responsive  to  the  SEP  Preparation  Guide? 

2.  Are  the  corporate  “enterprise”  processes  to  be  implemented  on  the  program  mature  and 
stable?  Is  any  tailoring  or  modifications  to  the  processes  appropriate  to  the  program? 

Does  the  tailoring  increase  cost,  schedule,  or  technical  risk?  Has  the  Offeror  made  a 
commitment  and  implemented  plans  for  continuous  process  improvement? 

3.  Are  the  major  technical  reviews  with  entry  and  exit  criteria  and  independent  SMEs 
included  in  the  SEP? 

4.  Has  a  single  technical  authority  for  the  program  been  identified?  Are  the  technical  team’s 
roles  and  responsibilities  within  the  Offeror’s  proposed  organization  been  clearly  defined 
and  assigned? 

5.  Has  the  skill,  experience  level,  and  corporate  commitment  of  key  technical  personnel  been 
identified?  Are  there  sufficient  manpower  resources  identified  and  available  to  support  the 
program?  Are  plans  for  transition  and  personnel  assignments  in  place  for  a  smooth  ramp- 
up  of  work  tasks  without  risk  of  delay? 

6.  Have  the  key  technical  processes  and  technical  management  processes  critical  to  program 
success  been  integrated  with  the  program  management  processes  and  reflect  the  technical 
approach  in  the  SEP  (e.g.,  requirements  management,  technical  baseline  management  and 
control,  risk  management,  earned  value  management,  supportability,  etc.)? 

IMP  andIMS Reference  3.2,2.3  and  3.2.4 _ 

Reference  IMP/IMS  §  5.1.8  guide  for  detailed  guidance  for  evaluation  of  an  IMP  and  IMS. 

1.  Are  the  SOW  tasks  reflected  in  the  IMP  and  IMS,  especially  the  technical  baseline 
management,  verification,  and  validation  tasks;  and  event-based  technical  reviews? 

Other  Management  Criteria  Reference  3. 2.2.4  and  3.2.4 

The  Other  Management  Criteria  proposal  instructions  should  focus  on  other  technical  related 
topics  that  might  be  critical  to  program  success,  and  each  program  should  carefully  select 
these  special  topics,  ensuring  they  are  important  discriminators  for  the  source.  Examples  of 
discriminating  processes  the  Government  might  seek  added  details  on  include:  risk 
management,  configuration  management  and  obsolescence  and  technology  insertion  planning. 
[Note:  to  the  extent  these  are  not  adequately  addressed  in  other  sections  of  the  proposal]. 
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_ Table  A-3  Technical  Focus  for  the  Past  Performance  Factor  Evaluation _ 

Past  Performance  Evaluation  Reference  3.2.3  and  3.2.4 

1 .  In  the  contracts  that  are  “relevant”  or  “highly  relevant,”  are  the  technical  approach  and 
domain  clearly  applicable  to  the  proposed  program?  Are  the  contracts  similar  in  scope;  do 
they  apply  the  same  technical  and  technical  management  processes  with  successful  results? 

2.  Is  technical  experience  of  teammates  and  subcontractors  relevant  to  the  allocation  of 
technical  tasks? 

3.  Do  the  responses  to  the  past  performance  questionnaire  show  excellent  systems 
engineering  past  performance?  Do  the  responses  support  the  Technical  and  Management 
Evaluation  Criteria  in  Section  M? 

4.  Have  the  systems  engineering  or  technical  element  in  Contractor  Performance  Assessment 
Reports  (CPAR)  been  considered?  Are  there  trends  or  systemic  issues  across  several 
CPAR  evaluations  that  indicate  potential  strengths  and/or  weaknesses  in  expected 
performance? 

5.  Do  low  CPAR  elements  have  a  “corrective  action”  plan  between  the  Government  customer 
and  the  contractor?  Is  the  corrective  action  on  schedule? 


_ Table  A-4  Technical  Focus  for  the  Cost  Factor  Evaluation _ 

Cost  Evaluation  Reference  3.2.5 

1 .  Does  the  cost  estimate  fully  represent  the  scope  of  the  technical  requirements  and  address 
all  the  work  and  delivery  requirements? 

2.  Do  the  cost  estimates  correlate  with  the  proposed  solution  and  technical  approach?  Is  the 
program  proposed  cost  estimate  for  the  technical  portions  of  the  program  reasonable  and 
realistic  based  on  your  judgment,  past  experience,  or  technical  knowledge?  Are  program 
cost,  schedule,  and  performance  balanced? 

3.  Are  the  processes,  the  organization,  the  technical  tasks  and  products  proposed  in  other 
sections  of  the  proposal  adequately  resourced  and  included  in  the  cost? 

4.  Are  the  technical  manpower  estimates  and  BOE  adequate  and  reasonable  for  the 
organization,  tasks,  and  schedule  reflected  in  the  IMP,  IMS,  and  SOW?  Does  the  skill 
level  of  the  manpower  reflect  the  complexity  of  the  tasks?  Is  the  BOE  supporting  rationale 
based  upon  credible  historical  data,  past  experience,  or  expert  judgment? 

5.  Is  the  time  phasing  of  the  resources  (manpower,  facilities,  and  infrastructure)  consistent 
with  the  IMP  Events  and  the  IMS  tasks  along  with  the  technical  approach  in  the  SEP? 

6.  Are  the  costs  consistent  with  their  proposed  technical  work  tasks,  products,  organization 
and  personnel  resources,  and  personnel  experience  level,  CWBS,  IMP,  IMS,  and  SEP? 

Technical  Questionsfor  the  WBS  Evaluation _ 

1.  Is  the  CWBS  based  on  the  deliverable  products  and  services  and  integrated  with  the 
program  organizational  structure  and  the  IMP? 

2.  Are  the  WBS  elements  clear  and  unambiguous?  Does  the  WBS  dictionary  adequately 
describe  the  systems  engineering  activities  included  in  other  proposal  documentation,  such 
as  the  SOW,  IMP,  IMS,  and  SEP? 

3.  Are  the  WBS  elements  clearly  and  uniquely  assigned  within  the  proposed  organization? 
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Table  A-5  Technical  Focus  for  the  Proposal  Risk  Assessment  Factor  Evaluation 

Proposal  Risk  Assessment  Reference  3.2.6 

1 .  Are  technical  claims  of  performance  supported  by  credible  analyses,  trade  studies,  or 
modeling  and  simulation  results? 

2.  Does  the  Offeror’s  domain  experience  support  the  program  approach  and  the  technical 
challenges  on  the  program?  Have  experienced  personnel  been  proposed  to  lead  the 
technical  activities  and  organization? 

3.  Are  the  technical  and  technical  management  processes  mature  and  stable,  and  are  the 
modifications  to  the  corporate  processes  appropriate  to  the  program?  Do  the  processes  (or 
lack  of  processes)  introduce  risk  into  the  program? 

4.  Are  there  corporate  plans  in  place  for  continued  process  improvement? 

5.  Have  the  key  technical  and  technical  management  processes  determined  critical  to 
program  success  been  integrated  into  the  program  management  and  technical  approach 
(e.g.,  configuration  management,  requirements  management,  technical  baseline  control, 
risk  management,  technology  insertion/obsolescence  planning,  modeling  and  simulation 
planning)?  Are  these  flowed  down  to  teammates,  subcontractors,  vendors,  and  suppliers, 
as  appropriate? 

6.  Are  the  technical  and  technical  management  processes  integrated  with  the  other  program 
management  processes  (EVMS,  IMP,  IMS,  and  CWBS)? 

7.  Have  the  technical  risks  been  evaluated  with  respect  to  their  relationship  to  the  program’s 
critical  path(s)?  Are  the  risk  mitigation  tasks  included  in  the  IMS?  Are  the  risk  mitigation 
tasks  reasonable,  complete,  and  appropriate  for  the  risk? 

8.  Is  the  program  schedule  reasonable  and  realistic?  Is  it  consistent  with  the  planned 
execution  of  the  program  as  stated  in  the  IMP,  IMS,  and  SEP?  Have  the  activities  on  and 
near  the  critical  path  been  evaluated? 
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(http://www.acq.osd.mil/ds/se/publications/pig/Policy  Addendum  for  Systems  Engineering  - 
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Risk  Management  Guide  for  DOD  Acquisition:  6th  edition;  version  1 .0;  August  2006 

(http://www.acq.osd.mil/se/ed/publications/2006%20RM%20Guide%20%204%20Aug%2006 
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Seven  Steps  to  Performance  Based  Services  Acquisition 

(http://www.amet.gov/comp/seven_steps/index.html) 

Systems  Engineering  Plan  (SEP)  Preparation  Guide.  10  February  2006 
(http://www.acq.osd.mil/se/publications/pig/sep_prepguide_vl_2.pdf) 

The  Defense  Acquisition  System.  DoDD  5000.1 
(http://akss.dau.mil/dag/DoD5000.asp?view=document&doc=l) 
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APPENDIX  C.  ABBREVIATIONS  AND  ACRONYMS 


ACC 

Acquisition  Community  Connection 

AoA 

Analysis  of  Alternatives 

APB 

Acquisition  Program  Baseline 

ASR 

Acquisition  Strategy  Report 

AT&L 

Acquisition,  Technology  and  Logistics 

A&T 

Acquisition  and  Technology 

BOE 

Basis  of  Estimate 

CDD 

Capability  Definition  Document 

CDR 

Critical  Design  Review 

CDRL 

Contract  Data  Requirements  List 

CLIN 

Contract  Line  Item  Number 

CM 

Configuration  Management 

CMMI 

Capability  Maturity  Model  Integration 

CO 

Contracting  Officer 

CONOPS 

Concept  of  Operations 

COTS 

Commercial-off-the-Shelf 

CPAR 

Contractor  Performance  Assessment  Report 

CPD 

Capability  Production  Document 

CR 

Concept  Refinement  phase 

CSOW 

Contractor  Statement  Of  Work 

CWBS 

Contract  Work  Breakdown  Structure 

DAG 

Defense  Acquisition  Guidebook 

DCMA 

Defense  Contract  Management  Agency 

DFARS 

Defense  Federal  Acquisition  Regulation  Supplement 

DoD 

Department  of  Defense 

DT&E 

Developmental  Test  and  Evaluation 

DUSD 

Deputy  Under  Secretary  of  Defense 

ED 

Enterprise  Development 

EVM 

Earned  Value  Management 

EVMS 

Earned  Value  Management  System 

FAR 

Federal  Acquisition  Regulation 

FCA 

Functional  Configuration  audit 

FoS 

Family-of-Systems 

GOTS 

Government-off  the-Shelf 

HSI 

Human  System  Interface 

IA 

Information  Assurance 

IT 

Information  Technology 

IBR 

Integrated  Baseline  Review 

ICD 

Initial  Capabilities  Document 

ICE 

Independent  Cost  Estimation 

IDE 

Integrated  Development  Environment 

IMP 

Integrated  Master  Plan 

IMS 

Integrated  Master  Schedule 

IPT 

Integrated  Product  Team 
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ISP 

Integrated  Support  Plan 

ISR 

In  Service  Review 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

KPP 

Key  Performance  Parameter 

LSE 

Lead  (or  Chief)  Systems  Engineer 

MOSA 

Modular  Open  Systems  Approach 

MR 

Material  Readiness 

M&C 

Monitor  and  Control 

M&S 

Modeling  and  Simulation 

OCI 

Organizational  Conflict  of  Interest 

OPR 

Office  of  Primary  Responsibility 

OSD 

Office  of  the  Secretary  of  Defense 

OTRR 

Operational  Test  Readiness  review 

OT&E 

Operational  Test  and  Evaluation 

OUSD 

Office  of  the  Under  Secretary  of  Defense  (AT&L) 

O&S 

Operations  and  Support  phase 

PBS  A 

Performance  Based  Services  Acquisition 

PCA 

Physical  Configuration  Audit 

PM 

Program  or  Project  Manger 

PRR 

Production  Readiness  Review 

PPIRS 

Past  Performance  Information  Retrieval  System 

PSP 

Product  Support  Plan 

PSS 

Product  Support  Strategy 

PWS 

Performance  Work  Statement 

P&D 

Production  and  Deployment  phase 

RFI 

Request  for  Information 

RFP 

Request  for  Proposal 

SDD 

System  Development  and  Demonstration  phase 

SDOE 

System  Design  and  Operational  Effectiveness 

SE 

Systems  Engineering 

SEIPT 

Systems  Engineering  IPT 

SEP 

Systems  Engineering  Plan 

SEMP 

Systems  Engineering  Management  Plan 

SME 

Subject  Matter  Expert 

SMR 

Sustainment  Material  Readiness 

SOE 

System  Operational  Effectiveness 

SOO 

Statement  of  Objectives 

SoS 

System-of-Systems 

SOW 

Statement  of  Work 

SPS 

System  Performance  Specification 

SSA 

Source  Selection  Authority 

SSE 

Systems  and  Software  Engineering 

SSEB 

Source  Selection  Evaluation  Board 

SSP 

Source  Selection  Plan 

SW 

Software 

SYR 

System  Verification  Review 
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TD  Technology  Development  phase 

TDS  Technology  Development  Strategy 

TEMP  Test  and  Evaluation  Master  Plan 

TES  Test  and  Evaluation  Strategy 

TLCSM  Total  Life  Cycle  System  Management 
TRA  Technology  Readiness  Assessment 

T&E  Test  and  Evaluation 

WBS  Work  Breakdown  Structure 


ODUSD  (A&T)  Systems  and  Software  Engineering/Enterprise  Development 

ATL-ED@osd.mil 


